Skip to main content

传输层安全性协议

传输层安全性协议（英语：Transport Layer Security，缩写作 TLS），及其前身安全套接层（Secure Sockets Layer，缩写作 SSL）是一种安全协议，目的是为互联网通信，提供安全及数据完整性保障。网景公司（Netscape）在1994年推出首版网页浏览器，网景导航者时，推出HTTPS协议，以SSL进行加密，这是SSL的起源。IETF将SSL进行标准化，1999年公布第一版TLS标准文件。随后又公布RFC 5246 （2008年8月）与 RFC 6176 （2011年3月）。在浏览器、电子邮件、即时通信、VoIP、网络传真等应用程序中，广泛支持这个协议。主要的网站，如Google、Facebook等也以这个协议来创建安全连接，发送数据。目前已成为互联网上保密通信的工业标准。
SSL包含记录层（Record Layer）和传输层，记录层协议确定传输层数据的封装格式。传输层安全协议使用X.509认证，之后利用非对称加密演算来对通信方做身份认证，之后交换对称密钥作为会谈密钥（Session key）。这个会谈密钥是用来将通信两方交换的数据做加密，保证两个应用间通信的保密性和可靠性，使客户与服务器应用之间的通信不被攻击者窃听。

概论[编辑]

TLS协议采用主从式架构模型，其目的在于提供两个应用程序间，通过网络的一个不安全通道，创建起安全的连接，来交换数据，防止数据受到窃听及篡改。
TLS协议的优势在于它是与应用层协议独立无关的。高层的应用层协议（例如：HTTP、FTP、Telnet等等）能透明的创建于TLS协议之上。TLS协议在应用层协议通信之前就已经完成加密算法、通信密钥的协商以及服务器认证工作。在此之后应用层协议所传送的数据都会被加密，从而保证通信的私密性。
TLS协议是可选的，所以如果需要使用就必须配置客户端和服务器，有两种主要方式实现这一目标：一个是使用统一的TLS协议通信端口（例如：用于HTTPS的端口443）；另一个是客户端请求服务器连接到TLS时使用特定的协议机制（例如：邮件、新闻协议和STARTTLS）。一旦客户端和服务器都同意使用TLS协议，他们通过使用一个握手过程协商出一个有状态的连接以传输数据[1]。通过握手，客户端和服务器协商各种参数用于创建安全连接：
  • 当客户端连接到支持TLS协议的服务器要求创建安全连接并列出了受支持的密码组合（加密密码算法和加密哈希函数），握手开始。
  • 服务器从该列表中决定加密和散列函数，并通知客户端。
  • 服务器发回其数字证书，此证书通常包含服务器的名称、受信任的证书颁发机构（CA）和服务器的公钥。
  • 客户端确认其颁发的证书的有效性。
  • 为了生成会话密钥用于安全连接，客户端使用服务器的公钥加密随机生成的密钥，并将其发送到服务器，只有服务器才能使用自己的私钥解密。
  • 利用随机数，双方生成用于加密和解密的对称密钥。这就是TLS协议的握手，握手完毕后的连接是安全的，直到连接（被）关闭。如果上述任何一个步骤失败，TLS握手过程就会失败，并且断开所有的连接。

发展历史[编辑]

定义
协议年份
SSL 1.0N/A
SSL 2.01995
SSL 3.01996
TLS 1.01999
TLS 1.12006
TLS 1.22008
TLS 1.3待定

安全网络编程[编辑]

早期的研究工作，为方便改造原有网络应用程序，在1993年已经有了相似的Berkeley套接字安全传输层API方法[2]。

SSL 1.0、2.0和3.0[编辑]

SSL（Secure Sockets Layer）是网景公司（Netscape）设计的主要用于Web的安全传输协议，这种协议在Web上获得了广泛的应用[3]。
基础算法由作为网景公司的首席科学家塔希尔·盖莫尔（Taher Elgamal）编写，所以他被人称为“SSL之父”。[4][5]
2014年10月，Google发布在SSL 3.0中发现设计缺陷，建议禁用此一协议。攻击者可以向TLS发送虚假错误提示，然后将安全连接强行降级到过时且不安全的SSL 3.0，然后就可以利用其中的设计漏洞窃取敏感信息。Google在自己公司相关产品中陆续禁止向后兼容，强制使用TLS协议。Mozilla也在11月25日发布的Firefox 34中彻底禁用了SSL 3.0。微软同样发出了安全通告[6]。
  • 1.0版本从未公开过，因为存在严重的安全漏洞。
  • 2.0版本在1995年2月发布，但因为存在数个严重的安全漏洞而被3.0版本替代[7]。
  • 3.0版本在1996年发布，是由网景工程师Paul Kocher、Phil Karlton和Alan Freier完全重新设计的。较新版本的SSL/TLS基于SSL 3.0。SSL 3.0作为历史文献IETF通过 RFC 6101 发表。

TLS 1.0[编辑]

IETF将SSL标准化，即 RFC 2246 ，并将其称为TLS（Transport Layer Security）。从技术上讲，TLS 1.0与SSL 3.0的差异非常微小。但正如RFC所述"the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough to preclude interoperability between TLS 1.0 and SSL 3.0"（本协议和SSL 3.0之间的差异并不是显著，却足以排除TLS 1.0和SSL 3.0之间的互操作性）。TLS 1.0包括可以降级到SSL 3.0的实现，这削弱了连接的安全性[8]:1–2。

TLS 1.1[编辑]

TLS 1.1在 RFC 4346 中定义，于2006年4月发表[9]，它是TLS 1.0的更新。在此版本中的差异包括：
  • 添加对CBC攻击的保护：
    • 隐式IV被替换成一个显式的IV。
    • 更改分组密码模式中的填充错误。
  • 支持IANA登记的参数。[8]:2

TLS 1.2[编辑]

TLS 1.2在 RFC 5246 中定义，于2008年8月发表。它基于更早的TLS 1.1规范。主要区别包括：
  • 可使用密码组合选项指定伪随机函数使用SHA-256替换MD5-SHA-1组合。
  • 可使用密码组合选项指定在完成消息的哈希认证中使用SHA-256替换MD5-SHA-1算法，但完成消息中哈希值的长度仍然被截断为96位。
  • 在握手期间MD5-SHA-1组合的数字签名被替换为使用单一Hash方法，默认为SHA-1。
  • 增强服务器和客户端指定Hash和签名算法的能力。
  • 扩大经过身份验证的加密密码，主要用于GCM和CCM模式的AES加密的支持。
  • 添加TLS扩展定义和AES密码组合[8]:2。所有TLS版本在2011年3月发布的RFC 6176中删除了对SSL的兼容，这样TLS会话将永远无法协商使用的SSL 2.0以避免安全问题。

TLS 1.3（草案）[编辑]

参见：椭圆曲线密码学和来回通信延迟
截至2016年1月，TLS 1.3还是一个互联网草案，细节尚属临时并且不完整[10][11]。它基于更早的TLS 1.2规范，与TLS 1.2的主要区别包括：
  • 移除脆弱和较少使用的命名椭圆曲线支持
  • 移除MD5和SHA-224密码散列函数的支持
  • 请求数字签名，即便使用之前的配置
  • 集成HKDF和半短暂DH提议
  • 替换使用PSK和票据的恢复
  • 支持1-RTT握手和初步支持0-RTT
  • 放弃许多不安全或过时特性的支持，包括数据压缩、重新协商、非AEAD密码本、静态RSA和静态DH密钥交换、自定义DHE分组、点格式协商、更改密码本规范的协议、UNIX时间的Hello消息，以及长度字段AD输入到AEAD密码本
  • 禁止用于向后兼容性的SSL和RC4协商
  • 集成会话散列的使用
  • 弃用记录层版本号和冻结数以改进向后兼容性
  • 将一些安全相关的算法细节从标准移动到标准，并将ClientKeyShare降级到附录
  • 添加Curve25519和Ed25519到TLS标准。

算法[编辑]

主条目：密码组合

密钥交换和密钥协商[编辑]

在客户端和服务器开始交换TLS所保护的加密信息之前，他们必须安全地交换或协定加密密钥和加密数据时要使用的密码。用于密钥交换的方法包括：使用RSA算法生成公钥和私钥（在TLS 握手协议中被称为TLS_RSA），Diffie-Hellman（在TLS握手协议中被称为TLS_DH），临时Diffie-Hellman（在TLS握手协议中被称为TLS_DHE），椭圆曲线迪菲-赫尔曼（在TLS握手协议中被称为TLS_ECDH），临时椭圆曲线Diffie-Hellman（在TLS握手协议中被称为TLS_ECDHE），匿名Diffie-Hellman（在TLS握手协议中被称为TLS_DH_anon）[12]和预共享密钥（在TLS握手协议中被称为TLS_PSK）。[13]
TLS_DH_anon和TLS_ECDH_anon的密钥协商协议不能验证服务器或用户，因为易受中间人攻击因此很少使用。只有TLS_DHE和TLS_ECDHE提供前向保密能力。
在交换过程中使用的公钥/私钥加密密钥的长度和在交换协议过程中使用的公钥证书也各不相同，因而提供的强健性的安全。2013年7月，Google宣布向其用户提供的TLS加密将不再使用1024位公钥并切换到2048位，以提高安全性。[14]
身份验证和密钥交换协议列表
算法SSL 2.0SSL 3.0TLS 1.0TLS 1.1TLS 1.2状态
RSA是是是是是在TLS 1.2的RFCs内定义
DH-RSA否是是是是
DHE-RSA（具有前向安全性）
ECDH-RSA否否是是是
ECDHE-RSA（具有前向安全性）
DH-DSS否是是是是
DHE-DSS（具有前向安全性）
ECDH-ECDSA否否是是是
ECDHE-ECDSA（具有前向安全性）
DH-ANON（不安全）否否是是是
ECDH-ANON（不安全）否否是是是
GOST R 34.10-94 / 34.10-2001[15]否否是是是RFC草案

加密密码[编辑]

参见：块密码的工作模式
已知公开并可行的攻击方法列表
密码协议版本状态
类型算法长度（位）SSL 2.0SSL 3.0
[n 1][n 2][n 3][n 4]		TLS 1.0
[n 1][n 3]		TLS 1.1
[n 1]		TLS 1.2
[n 1]
块密码AES GCM[16][n 5]256, 128不适用不适用不适用不适用安全在TLS 1.2的RFCs中定义
AES CCM[17][n 5]不适用不适用不适用不适用安全
AES CBC[n 6]不适用不适用依赖于后期加入的措施安全安全
Camellia GCM[18][n 5]256, 128不适用不适用不适用不适用安全
Camellia CBC[19][n 6]不适用不适用依赖于后期加入的措施安全安全
ARIA GCM[20][n 5]256, 128不适用不适用不适用不适用安全
ARIA CBC[20][n 6]不适用不适用依赖于后期加入的措施安全安全
SEED CBC[21][n 6]128不适用不适用依赖于后期加入的措施安全安全
3DES EDE CBC[n 6]112 不安全不安全强度不足
依赖于后期加入的措施		强度不足强度不足
GOST 28147-89 CNT[15]256不适用不适用安全安全安全RFC草案
IDEA CBC[n 6][n 8]128不安全不安全依赖于后期加入的措施安全不适用在TLS 1.2中已被移除
DES CBC[n 6][n 8]56不安全不安全不安全不安全不适用
40[n 9]不安全不安全不安全不适用不适用在TLS 1.1及更高版本中被禁用
RC2 CBC[n 6]40[n 9]不安全不安全不安全不适用不适用
流密码RC4[n 10]128不安全不安全不安全不安全不安全在TLS 1.2的RFCs中定义
40[n 9]不安全不安全不安全不适用不适用在TLS 1.1以后的版本中被禁用
ChaCha20-Poly1305[25][n 5]256不适用不适用不适用不适用安全RFC草案
ChaCha20[26]256不适用不适用安全安全安全
不加密无[n 11]-不适用不安全不安全不安全不安全在TLS 1.2的RFCs中定义
标注
  1. ^ 跳转至：1.0 1.1 1.2 1.3 RFC 5746必须执行，修补重协商漏洞。
  2. 跳转^ 如果库实现修复RFC 5746中列出的问题将违反SSL 3.0规范，与TLS不同的是IETF无法更改SSL协议的设计。幸运的是，最新的库实现已经修复并忽略违反规范的问题。
  3. ^ 跳转至：3.0 3.1 除非服务器和客户端双方都已经修复，BEAST能攻击所有使用SSL 3.0和TLS 1.0的CBC数据块。
  4. 跳转^ 除非服务器和客户端双方都已经修复，POODLE能攻击所有使用SSL 3.0的CBC数据块。
  5. ^ 跳转至：5.0 5.1 5.2 5.3 5.4 AEAD密码（例如GCM和CCM模式）只能用于TLS 1.2。
  6. ^ 跳转至：6.0 6.1 6.2 6.3 6.4 6.5 6.6 6.7 如果库实现处理边缘计时器不严密，CBC密码可以通过Lucky 13被攻击。
  7. 跳转^ 虽然3DES的密钥长度是168位，但有效的安全强度只有112位，[22]而现在最低的安全要求是128位[23]。
  8. ^ 跳转至：8.0 8.1 IDEA和DES在TLS 1.2中已被移除[24]。
  9. ^ 跳转至：9.0 9.1 9.2 40位强度的密码组合是为了减少密钥长度，以遵守包含某些功能强大的加密算法的加密软件在出口方面的规定，这些弱密码组合在TLS 1.1及更高版本中已被禁用。
  10. 跳转^ RC4攻击削弱了RC4在SSL/TLS中的使用。
  11. 跳转^ 只认证，不加密

数据完整性[编辑]

消息认证码（MAC）用于对数据完整性进行认证。HMAC用于CBC模式的块密码和流密码，AEAD用于身份验证加密例如GCM模式和CCM模式。
数据完整性算法列表
算法SSL 2.0SSL 3.0TLS 1.0TLS 1.1TLS 1.2状态
HMAC-MD5是是是是是在TLS 1.2的RFCs中定义
HMAC-SHA1否是是是是
HMAC-SHA256/384否否否否是
AEAD否否否否是
GOST 28147-89 IMIT[15]否否是是是RFC草案
GOST R 34.11-94[15]否否是是是

过程[编辑]

双向证书认证的SSL握手过程。
以下简要介绍SSL协议的工作方式。客户端要收发几个握手信号：
  1. 发送一个“ClientHello”消息，内容包括：支持的协议版本，比如TLS1.0版，一个客户端生成的随机数（稍后用于生成“会话密钥”），支持的加密算法（如RSA公钥加密）和支持的压缩算法。
  2. 然后收到一个“ServerHello”消息，内容包括：确认使用的加密通信协议版本，比如TLS 1.0版本（如果浏览器与服务器支持的版本不一致，服务器关闭加密通信），一个服务器生成的随机数（稍后用于生成“对话密钥”），确认使用的加密方法（如RSA公钥加密），服务器证书。
  3. 当双方知道了连接参数，客户端与服务器交换证书（依靠被选择的公钥系统）。这些证书通常基于X.509，不过已有草案支持以OpenPGP为基础的证书。
  4. 服务器请求客户端公钥。客户端有证书即双向身份认证，没证书时随机生成公钥。
  5. 客户端与服务器通过公钥保密协商共同的主私钥（双方随机协商），这通过精心谨慎设计的伪随机数功能实现。结果可能使用Diffie-Hellman交换，或简化的公钥加密，双方各自用私钥解密。所有其他关键数据的加密均使用这个“主密钥”。数据传输中记录层（Record layer）用于封装更高层的HTTP等协议。记录层数据可以被随意压缩、加密，与消息验证码压缩在一起。每个记录层包都有一个Content-Type段用以记录更上层用的协议。

TLS[编辑]

TLS利用密钥算法在互联网上提供端点身份认证与通讯保密，其基础是公钥基础设施。不过在实现的典型例子中，只有网络服务者被可靠身份验证，而其客户端则不一定。这是因为公钥基础设施普遍商业运营，电子签名证书通常需要付费购买。协议的设计在某种程度上能够使主从架构应用程序通讯本身预防窃听、干扰和消息伪造。
TLS包含三个基本阶段：
  1. 对等协商支持的密钥算法
  2. 基于非对称密钥的信息传输加密和身份认证、基于PKI证书的身份认证
  3. 基于对称密钥的数据传输保密
在第一阶段，客户端与服务器协商所用密码算法。当前广泛实现的算法选择如下：
TLS/SSL有多样的安全保护措施：
  • 所有的记录层数据均被编号，用于消息验证码校验。
Labels:

Comments

Post a Comment

https://gengwg.blogspot.com/

Popular posts from this blog

OWASP Top 10 Threats and Mitigations Exam - Single Select

Last updated 4 Aug 11 Course Title: OWASP Top 10 Threats and Mitigation Exam Questions - Single Select 1) Which of the following consequences is most likely to occur due to an injection attack? Spoofing Cross-site request forgery Denial of service   Correct Insecure direct object references 2) Your application is created using a language that does not support a clear distinction between code and data. Which vulnerability is most likely to occur in your application? Injection   Correct Insecure direct object references Failure to restrict URL access Insufficient transport layer protection 3) Which of the following scenarios is most likely to cause an injection attack? Unvalidated input is embedded in an instruction stream.   Correct Unvalidated input can be distinguished from valid instructions. A Web application does not validate a client’s access to a resource. A Web action performs an operation on behalf of the user without checking a shared sec
2 comments
Read more

CKA Simulator Kubernetes 1.22

  https://killer.sh Pre Setup Once you've gained access to your terminal it might be wise to spend ~1 minute to setup your environment. You could set these: alias k = kubectl                         # will already be pre-configured export do = "--dry-run=client -o yaml"     # k get pod x $do export now = "--force --grace-period 0"   # k delete pod x $now Vim To make vim use 2 spaces for a tab edit ~/.vimrc to contain: set tabstop=2 set expandtab set shiftwidth=2 More setup suggestions are in the tips section .     Question 1 | Contexts Task weight: 1%   You have access to multiple clusters from your main terminal through kubectl contexts. Write all those context names into /opt/course/1/contexts . Next write a command to display the current context into /opt/course/1/context_default_kubectl.sh , the command should use kubectl . Finally write a second command doing the same thing into /opt/course/1/context_default_no_kubectl.sh , but without the use of k
Post a Comment
Read more

标 题: 关于Daniel Guo 律师

发信人: q123452017 (水天一色), 信区: I140 标  题: 关于Daniel Guo 律师 关键字: Daniel Guo 发信站: BBS 未名空间站 (Thu Apr 26 02:11:35 2018, 美东) 这些是lz根据亲身经历在 Immigration版上发的帖以及一些关于Daniel Guo 律师的回 帖，希望大家不要被一些马甲帖广告帖所骗，慎重考虑选择律师。 WG 和Guo两家律师对比 1. fully refund的合约上的区别 wegreened家是case不过只要第二次没有file就可以fully refund。郭家是要两次case 没过才给refund，而且只要第二次pl draft好律师就可以不退任何律师费。 2. 回信速度 wegreened家一般24小时内回信。郭律师是在可以快速回复的时候才回复很快，对于需 要时间回复或者是不愿意给出确切答复的时候就回复的比较慢。 比如：lz问过郭律师他们律所在nsc区域最近eb1a的通过率，大家也知道nsc现在杀手如 云，但是郭律师过了两天只回复说让秘书update最近的case然后去网页上查，但是上面 并没有写明tsc还是nsc。 lz还问过郭律师关于准备ps （他要求的文件）的一些问题，模版上有的东西不是很清 楚，但是他一般就是把模版上的东西再copy一遍发过来。 3. 材料区别 （推荐信） 因为我只收到郭律师写的推荐信，所以可以比下两家推荐信 wegreened家推荐信写的比较长，而且每封推荐信会用不同的语气和风格，会包含lz写 的research summary里面的某个方面 郭家四封推荐信都是一个格式，一种语气，连地址，信的称呼都是一样的，怎么看四封 推荐信都是同一个人写出来的。套路基本都是第一段目的，第二段介绍推荐人，第三段 某篇或几篇文章的abstract，最后结论 4. 前期材料准备 wegreened家要按照他们的模版准备一个十几页的research summary。 郭律师在签约之前说的是只需要准备五页左右的summary，但是在lz签完约收到推荐信 ，郭律师又发来一个很长的ps要lz自己填，而且和pl的格式基本差不多。 总结下来，申请自己上心最重要。但是如果选律师，lz更倾向于wegreened，
Post a Comment
Read more