族谱网 头条 人物百科

传输层安全协议

2020-10-16
出处:族谱网
作者:阿族小谱
浏览:426
转发:0
评论:0
概论TLS协议采用主从式架构模型,其目的在于提供两个应用程序间,通过网络的一个不安全通道,创建起安全的连接,来交换数据,防止数据受到窃听及篡改。TLS协议的优势在于它是与应用层协议独立无关的。高层的应用层协议(例如:HTTP、FTP、Telnet等等)能透明的创建于TLS协议之上。TLS协议在应用层协议通信之前就已经完成加密算法、通信密钥的协商以及服务器认证工作。在此之后应用层协议所传送的数据都会被加密,从而保证通信的私密性。TLS协议是可选的,所以如果需要使用就必须配置客户端和服务器,有两种主要方式实现这一目标:一个是使用统一的TLS协议通信端口(例如:用于HTTPS的端口443);另一个是客户端请求服务器连接到TLS时使用特定的协议机制(例如:邮件、新闻协议和STARTTLS)。一旦客户端和服务器都同意使用TLS协议,他们通过使用一个握手过程协商出一个有状态的连接以传输数据。通过握手,...

概论

TLS协议采用主从式架构模型,其目的在于提供两个应用程序间,通过网络的一个不安全通道,创建起安全的连接,来交换数据,防止数据受到窃听及篡改。

TLS协议的优势在于它是与应用层协议独立无关的。高层的应用层协议(例如:HTTP、FTP、Telnet等等)能透明的创建于TLS协议之上。TLS协议在应用层协议通信之前就已经完成加密算法、通信密钥的协商以及服务器认证工作。在此之后应用层协议所传送的数据都会被加密,从而保证通信的私密性。

TLS协议是可选的,所以如果需要使用就必须配置客户端和服务器,有两种主要方式实现这一目标:一个是使用统一的TLS协议通信端口(例如:用于HTTPS的端口443);另一个是客户端请求服务器连接到TLS时使用特定的协议机制(例如:邮件、新闻协议和STARTTLS)。一旦客户端和服务器都同意使用TLS协议,他们通过使用一个握手过程协商出一个有状态的连接以传输数据 。通过握手,客户端和服务器协商各种参数用于创建安全连接:

当客户端连接到支持TLS协议的服务器要求创建安全连接并列出了受支持的密码组合(加密密码算法和加密哈希函数),握手开始。

服务器从该列表中决定加密和散列函数,并通知客户端。

服务器发回其数字证书,此证书通常包含服务器的名称、受信任的证书颁发机构(CA)和服务器的公钥。

客户端确认其颁发的证书的有效性。

为了生成会话密钥用于安全连接,客户端使用服务器的公钥加密随机生成的密钥,并将其发送到服务器,只有服务器才能使用自己的私钥解密。

利用随机数,双方生成用于加密和解密的对称密钥。这就是TLS协议的握手,握手完毕后的连接是安全的,直到连接(被)关闭。如果上述任何一个步骤失败,TLS握手过程就会失败,并且断开所有的连接。

发展历史

安全网络编程

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

SSL 1.0、2.0和3.0

SSL( Secure Sockets Layer )是网景公司(Netscape)设计的主要用于Web的安全传输协议,这种协议在Web上获得了广泛的应用 。

基础算法由作为网景公司的首席科学家塔希尔·盖莫尔(Taher Elgamal)编写,所以他被人称为“SSL之父”。

2014年10月,Google发布在SSL 3.0中发现设计缺陷,建议禁用此一协议。攻击者可以向TLS发送虚假错误提示,然后将安全连接强行降级到过时且不安全的SSL 3.0,然后就可以利用其中的设计漏洞窃取敏感信息。Google在自己公司相关产品中陆续禁止向后兼容,强制使用TLS协议。Mozilla也在11月25日发布的Firefox34中彻底禁用了SSL 3.0。微软同样发出了安全通告 。

1.0版本从未公开过,因为存在严重的安全漏洞。

2.0版本在1995年2月发布,但因为存在数个严重的安全漏洞而被3.0版本替代 。

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的实现,这削弱了连接的安全性 。

TLS 1.1

TLS 1.1在 RFC 4346 中定义,于2006年4月发表 ,它是TLS 1.0的更新。在此版本中的差异包括:

添加对CBC攻击的保护:

支持IANA登记的参数。

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密码组合 。所有TLS版本在2011年3月发布的RFC 6176中删除了对SSL的兼容,这样TLS会话将永远无法协商使用的SSL 2.0以避免安全问题。

TLS 1.3(草案)

截至2016年1月 ( 2016-01 ) ,TLS 1.3还是一个 互联网草案 ( 英语 : Internet Draft ) ,细节尚属临时并且不完整 。它基于更早的TLS 1.2规范,与TLS 1.2的主要区别包括:

移除脆弱和较少使用的命名椭圆曲线支持

移除MD5和SHA-224密码散列函数的支持

请求数字签名,即便使用之前的配置

集成 HKDF ( 英语 : Key derivation function ) 和半短暂DH提议

替换使用 PSK ( 英语 : TLS-PSK ) 和票据的恢复

支持1-RTT握手和初步支持0-RTT

放弃许多不安全或过时特性的支持,包括数据压缩、重新协商、非 AEAD ( 英语 : Authenticated encryption ) 密码本、静态RSA和静态DH密钥交换、自定义DHE分组、点格式协商、更改密码本规范的协议、UNIX时间的Hello消息,以及长度字段AD输入到AEAD密码本

禁止用于向后兼容性的SSL和RC4协商

集成会话散列的使用

弃用记录层版本号和冻结数以改进向后兼容性

将一些安全相关的算法细节从标准移动到标准,并将ClientKeyShare降级到附录

添加 Curve25519 ( 英语 : Curve25519 ) 和 Ed25519 ( 英语 : 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) 和预共享密钥(在TLS握手协议中被称为TLS_PSK)。

TLS_DH_anon和TLS_ECDH_anon的密钥协商协议不能验证服务器或用户,因为易受中间人攻击因此很少使用。只有TLS_DHE和TLS_ECDHE提供前向保密能力。

在交换过程中使用的公钥/私钥加密密钥的长度和在交换协议过程中使用的公钥证书也各不相同,因而提供的 强健性 的安全。2013年7月,Google宣布向其用户提供的TLS加密将不再使用1024位公钥并切换到2048位,以提高安全性。

加密密码

数据完整性

消息认证码(MAC)用于对数据完整性进行认证。HMAC用于CBC模式的块密码和流密码,AEAD用于身份验证加密例如GCM模式和CCM模式。

过程

传输层安全协议

  双向证书认证的SSL握手过程。

以下简要介绍SSL协议的工作方式。客户端要收发几个握手信号:

发送一个“ ClientHello ”消息,内容包括:支持的协议版本,比如TLS1.0版,一个客户端生成的随机数(稍后用于生成“会话密钥”),支持的加密算法(如RSA公钥加密)和支持的压缩算法。

然后收到一个“ ServerHello ”消息,内容包括:确认使用的加密通信协议版本,比如TLS 1.0版本(如果浏览器与服务器支持的版本不一致,服务器关闭加密通信),一个服务器生成的随机数(稍后用于生成“对话密钥”),确认使用的加密方法(如RSA公钥加密),服务器证书。

当双方知道了连接参数,客户端与服务器交换证书(依靠被选择的公钥系统)。这些证书通常基于X.509,不过已有草案支持以OpenPGP为基础的证书。

服务器请求客户端公钥。客户端有证书即双向身份认证,没证书时随机生成公钥。

客户端与服务器通过公钥保密协商共同的主私钥(双方随机协商),这通过精心谨慎设计的伪随机数功能实现。结果可能使用Diffie-Hellman交换,或简化的公钥加密,双方各自用私钥解密。所有其他关键数据的加密均使用这个“主密钥”。数据传输中记录层(Record layer)用于封装更高层的HTTP等协议。记录层数据可以被随意压缩、加密,与消息验证码压缩在一起。每个记录层包都有一个 Content-Type 段用以记录更上层用的协议。

TLS

TLS利用密钥算法在互联网上提供端点身份认证与通讯保密,其基础是公钥基础设施。不过在实现的典型例子中,只有网络服务者被可靠身份验证,而其客户端则不一定。这是因为公钥基础设施普遍商业运营,电子签名证书通常需要付费购买。协议的设计在某种程度上能够使主从架构应用程序通讯本身预防窃听、干扰和消息伪造。

TLS包含三个基本阶段:

对等协商支持的密钥算法

基于非对称密钥的信息传输加密和身份认证、基于PKI证书的身份认证

基于对称密钥的数据传输保密

在第一阶段,客户端与服务器协商所用密码算法。当前广泛实现的算法选择如下:

公钥私钥非对称密钥保密系统:RSA、Diffie-Hellman、DSA;

对称密钥保密系统:RC2、RC4、IDEA、DES、Triple DES、AES以及Camellia;

单向散列函数:MD5、SHA1以及SHA256。

TLS/SSL有多样的安全保护措施:

所有的记录层数据均被编号,用于消息验证码校验。

参见

扩展验证证书

SSL/TLS/WTLS原理

SSL配置指南

SSL状态检查、格式转换、漏洞扫描工具


免责声明:以上内容版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。感谢每一位辛勤著写的作者,感谢每一位的分享。

——— 没有了 ———
编辑:阿族小谱
发表评论
写好了,提交
{{item.label}}
{{commentTotal}}条评论
{{item.userName}}
发布时间:{{item.time}}
{{item.content}}
回复
举报
点击加载更多
打赏作者
“感谢您的打赏,我会更努力的创作”
— 请选择您要打赏的金额 —
{{item.label}}
{{item.label}}
打赏成功!
“感谢您的打赏,我会更努力的创作”
返回

更多文章

更多精彩文章
打赏
私信

推荐阅读

· 超文本传输安全协议
主要思想更多资料:传输层安全HTTPS的主要思想是在不安全的网络上创建一安全信道,并可在使用适当的加密包和服务器证书可被验证且可被信任时,对窃听和中间人攻击提供合理的防护。HTTPS的信任继承基于预先安装在浏览器中的证书颁发机构(如VeriSign、Microsoft等)(意即“我信任证书颁发机构告诉我应该信任的”)。因此,一个到某网站的HTTPS连接可被信任,当且仅当:用户相信他们的浏览器正确实现了HTTPS且安装了正确的证书颁发机构;用户相信证书颁发机构仅信任合法的网站;被访问的网站提供了一个有效的证书,意即,它是由一个被信任的证书颁发机构签发的(大部分浏览器会对无效的证书发出警告);或者互联网上相关的节点是值得信任的,或者用户相信本协议的加密层(TLS或SSL)不能被窃听者破坏。浏览器实现当连接到一个提供无效证书的网站时,较旧的浏览器会使用一对话框询问用户是否继续,而较新的浏览器会在...
· 传输层
服务传输层服务通过传输层协议的编程接口传递给应用进程。该服务可以包括以下功能:连接导向式通信:通常对于一个应用进程来说,把连接解读为数据流(英语:datastream)而非处理底层的无连接模型(如用户数据报协议(UDP)与网际协议(IP)的数据报文模型)更加容易。相同次序交付:网络层通常不保证数据包到达顺序与发送顺序相同,但这往往是一个可取的特点。这通常是通过给报文段编号来完成的,接收者按次序将它们传给应用进程。这可能会造成队头阻塞。可靠性:由于网络拥塞和错误,数据包可能在传输过程中丢失。通过检错码(如校验和),传输协议可以检查数据是否损坏,并通过向发送者传ACK或NACK消息确认正确接收。自动重发请求方案可用于重新传输丢失或损坏的数据。流量控制(英语:Flowcontrol(data)):有时必须控制两个节点之间的数据传输速率以阻止快速的发送者传输超出接收缓冲器所能承受的数据,造成缓冲区...
· 安全协议
安全协议的目标安全目标是多种多样的。例如,认证协议的目标是认证参加协议的实体的身份。此外,许多认证协议还有一个附加的目标,即在主体之间安全地分配密钥或其他各种秘密。安全协议的分类按安全协议定义密钥交换协议、认证协议、认证和密钥交换协议。按安全协议实现的功能认证协议、最小泄密协议、不可否认协议、公平性协议、身份识别协议、密钥管理协议。针对安全协议的攻击对于攻击者能力的假设Dolev-Yao模型认为,攻击者可以控制整个通信网络,并应当假定攻击者具有相应的知识与能力。例如,我们应当假定,攻击者除了可以窃听、阻止、截获所有经过网络的消息等之外,还应具备以下知识和能力:熟悉加解、解密、散列(hash)等密码运算,拥有自己的加密密钥和解密密钥;熟悉参与协议的主体标识符及其公钥;具有密码分析的知识和能力;具有进行各种攻击,例如重放攻击的知识和能力。攻击类型安全协议的设计设计原则形式化描述语言基本假设安全...
· 传输控制协议
运作方式TCP连接包括三个状态:连接创建、数据传送和连接终止。操作系统将TCP连接抽象为套接字的编程接口给程序使用,并且要经历一系列的状态改变。创建通路TCP用三路握手(three-wayhandshake)过程创建一个连接。在连接创建过程中,很多参数要被初始化,例如序号被初始化以保证按序传输和连接的强壮性。TCP连接的正常创建一对终端同时初始化一个它们之间的连接是可能的。但通常是由一端打开一个套接字(socket)然后监听来自另一方的连接,这就是通常所指的被动打开(passiveopen)。服务器端被被动打开以后,用户端就能开始创建主动打开(activeopen)。客户端通过向服务器端发送一个SYN来创建一个主动打开,作为三路握手的一部分。客户端把这段连接的序号设定为随机数A。服务器端应当为一个合法的SYN回送一个SYN/ACK。ACK的确认码应为A+1,SYN/ACK包本身又有一个随机...
· 文件传输协议
FTPserver历史文件传输协议的原始规范于1971年4月16日发布为RFC114。直到1980年,FTP运行在TCP/IP的前身NCP上。该协议后来被TCP/IP版本,RFC765(1980年6月)和RFC959(1985年10月)(当前规范)所取代。RFC959提出了若干标准修改,例如RFC1579(1994年2月)启用防火墙FTP(被动模式),RFC2228(1997年6月)提出安全扩展,RFC2428(1998年9月)增加了对IPv6的支持,并定义了一种新型的被动模式。概述FTP服务一般运行在20和21两个端口。端口20用于在客户端和服务器之间传输数据流,而端口21用于传输控制流,并且是命令通向ftp服务器的进口。当数据通过数据流传输时,控制流处于空闲状态。而当控制流空闲很长时间后,客户端的防火墙会将其会话置为超时,这样当大量数据通过防火墙时,会产生一些问题。此时,虽然文件可以成...

关于我们

关注族谱网 微信公众号,每日及时查看相关推荐,订阅互动等。

APP下载

下载族谱APP 微信公众号,每日及时查看
扫一扫添加客服微信