SSL和TLS之间的区别


Answers:


59

简而言之,TLSv1.0或多或少是SSLv3.1。您可以在ServerFault的此问题中找到更多详细信息。

正如本研究表明的那样,大多数网站实际上至少都支持SSLv3和TLSv1.0 (Lee,Malkin和Nahum的论文:SSL / TLS服务器的加密强度:当前和近期实践,IMC 2007)(从IETF TLS列表获得的链接)。超过98%的用户支持TLSv1 +。

我认为仍然使用SSLv3的原因是为了支持旧版(尽管如今大多数浏览器都支持TLSv1和某些TLSv1.1甚至是TLSv1.2)。直到不久之前,默认情况下,某些发行版还与其他发行版一起启用了SSLv2(认为不安全)。

(您可能还会发现这个问题很有趣,尽管它与TLS而不是SSL与TLS的使用方式有关(实际上您可能与SSL具有相同的使用方式)。无论如何这不适用于HTTPS,因为HTTPS使用SSL / TLS从连接开始。)


23

来自http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/

在90年代初,万维网的曙光中,Netscape的一些工程师开发了一种用于发出安全HTTP请求的协议,他们提出的协议称为SSL。鉴于当时有关安全协议的知识相对匮乏,以及Netscape的每个人都在承受巨大的压力,他们的努力只能被视为英雄般的英雄。与同一个年份的许多其他协议相比,SSL能够持续这么长时间真是令人惊讶。从那时起,我们肯定已经学到了很多东西,但是关于协议和API的事情是,回头路不多了。

SSL协议有两个主要更新,SSL 2(1995)和SSL 3(1996)。这些都是为了向后兼容而精心设计的,以便于采用。但是向后兼容是安全协议的约束,它可能意味着向后易受攻击。

因此,决定打破向后兼容性,并使用了名为TLS 1.0(1999)的新协议。(事后看来,将其命名为TLS 4可能更清楚了)

该协议与SSL 3.0之间的差异并不明显,但它们之间的差异非常大,以至于TLS 1.0和SSL 3.0无法互操作。

TLS已进行了两次修订,分别是TLS 1.1(2006)和TLS 1.2(2008)。

截至2015年,所有SSL版本均已损坏且不安全(POODLE攻击),并且浏览器正在删除支持。TLS 1.0无处不在,但是只有60%的站点支持TLS 1.1和1.2,这是一种令人遗憾的状况。


如果您对此东西感兴趣,我建议在https://www.youtube.com/watch?v=Z7Wl2FW2TcA上推荐Moxie Marlinspike的聪明有趣的演讲


我记得在1980年代后期,一个Usenet news:comp.sources.unix帖子叫做Secure Sockets Layer。我怀疑它与Netscape除名称外是否有任何关系。
罗恩侯爵,

11

tls1.0表示sslv3.1

tls1.1表示sslv3.2

tls1.2表示sslv3.3

射频(RFC)刚刚更改了名称,您会发现tls1.0的十六进制代码为0x0301,即sslv3.1


2

TLS保持与SSL的向后兼容性,因此在本文提到的任何版本中,通信协议几乎相同。SSL v.3,TLS 1.0和TLS 1.2之间的两个重要区别是伪随机函数(PRF)和HMAC哈希函数(SHA,MD5,握手),该函数用于构造一个对称密钥块,用于应用程序数据加密(服务器密钥+客户端密钥+ IV)。TLS 1.1和TLS 1.2之间的主要区别在于,1.2需要使用“显式” IV来防御CBC攻击,尽管为此不需要更改PRF或协议。TLS 1.2 PRF是特定于密码套件的,这意味着可以在握手期间协商PRF。SSL最初由Netscape Communications(历史性)开发,后来由Internet工程任务组(IETF,当前)维护。TLS由网络工作组维护。以下是TLS中的PRF HMAC函数之间的区别:

TLS 1.0和1.1

PRF(秘密,标签,种子)= P_MD5(S1,标签+种子)XOR P_SHA-1(S2,标签+种子);

TLS 1.2

PRF(秘密,标签,种子)= P_hash(秘密,标签+种子)


0

“如果它没有损坏,请不要触摸它”。SSL3在大多数情况下都可以正常工作(十月份的SSL / TLS协议中存在一个基本缺陷,但这是应用程序的缺陷,而不是procol本身),因此开发人员不必着急升级其SSL模块。TLS带来了许多有用的扩展和安全算法,但是它们是方便添加的,不是必须的。因此,大多数服务器上的TLS仍然是一个选择。如果服务器和客户端都支持它,则将使用它。

更新:在'2016 SSL 3中,甚至发现TLS最高1.2也容易受到各种攻击,因此建议迁移到TLS 1.2。TLS 1.2的实现也存在攻击,尽管它们与服务器有关。TLS 1.3目前正在开发中。现在,TLS 1.2是必须的。


2
不,这是一个协议缺陷,开发人员应升级其SSL堆栈。话虽如此,除了针对TLS的准则外,还有针对SSLv3的RFC 5746中使用重新协商扩展的准则。
布鲁诺

如果您用刀杀死某人,这不是刀的缺陷,而是您的大脑之一。同样在这里。如果协议的使用方式不符合设计目的,则说明该协议不是缺陷。
Eugene Mayevski'Callback

1
该协议的设计方式是使其之上的应用程序应尽可能将其视为普通套接字。没有新扩展名的重新协商问题迫使应用程序层(例如HTTP)意识到这一点。IETF TLS邮件列表中有关于此主题的有趣主题:ietf.org/mail-archive/web/tls/current/msg04000.html
Bruno

1
我同意其中一些应在应用程序级别完成,但是我不知道任何实现方式和协议都考虑到了这一点。堆栈通常可以应对重新协商的问题,即它们是合法发起的,但是如果MITM发起了,则协议的谈判量就不那么多了(这就是问题所在)。这就是为什么IETF TLS组选择在TLS级别上对其进行修复的原因,这也是为什么人们真的应该打开该扩展名或完全禁用重新协商的原因。
布鲁诺

1
SSL 3.0中存在比您提到的更为根本的问题。例如,CBC填充oracle,以及重新使用IV或以前的记录。前者仍然困扰着TLS,但可以解决,而后者已固定在TLS 1.1上。
Nikos,

0

https://hpbn.co/transport-layer-security-tls/是一个很好的介绍

SSL协议最初是由Netscape开发的,旨在实现Web上电子商务交易的安全性,该协议需要加密以保护客户的个人数据,并需要进行身份验证和完整性保证以确保交易安全。为了实现此目的,SSL协议是在应用程序层上直接在TCP之上实现的(图4-1),使它之上的协议(HTTP,电子邮件,即时消息传递和许多其他协议)保持不变,同时在以下情况下提供了通信安全性:通过网络通信。

正确使用SSL后,第三方观察者只能推断出连接端点,加密类型,发送频率和近似数据量,而不能读取或修改任何实际数据。

SSL 2.0是该协议的第一个公开发布的版本,但是由于发现了许多安全漏洞,因此很快被SSL 3.0取代。由于SSL协议是Netscape专有的,因此IETF致力于标准化该协议,从而产生了RFC 2246,该文件于1999年1月发布,并被称为TLS 1.0。自那时以来,IETF一直在迭代该协议以解决安全漏洞并扩展其功能:TLS 1.1(RFC 2246)于2006年4月发布,TLS 1.2(RFC 5246)于2008年8月发布,目前正在开展工作正在定义TLS 1.3。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.