建立的HTTPS连接是否意味着线路确实安全？

#1 楼

重要的是要了解SSL可以做什么和不可以做什么，尤其是因为这是一个非常普遍的误解源。


它加密通道
应用完整性检查
提供身份验证

因此，快速答案应该是：“是，它足以传输敏感数据”。但是，事情并不是那么简单。


SSL的最新版本-版本3或更高版本：TLS（甚至TLS 1.2）绝对比以前的版本更好。例如。 SSL 2对MITM来说相对容易（中间是男人）。因此，首先取决于协议版本。
通道加密和完整性检查均可在协议中配置，即您可以选择要使用的算法（密码套件）。显然，如果您使用的是RSA1024 / SHA512，那就更好了……但是，SSL甚至支持NULL加密模式-即完全不加密，只是将请求打包到SSL协议中即可。即没有保护。 （这可以在客户端和服务器上进行配置，所选密码套件是根据配置顺序的第一个匹配集）。
SSL中的身份验证有两种模式：仅服务器身份验证和相互身份验证（客户端证书）。在这两种情况下，加密证书确保的安全性绝对足够强，但是实际身份验证的有效性仅与有效性检查一样好：您是否还要检查证书？您确保其有效性吗？信任链？谁发行的？等等
最后一点重新身份验证在Web应用程序中要容易得多，其中客户端可以轻松查看服务器证书，可以轻松查看锁定图标等。使用Web Services，通常需要更加明确地检查其有效性（取决于您选择的平台）。请注意，同一点已经使许多移动应用程序崩溃-即使应用程序开发人员记得在电话和服务器之间仅使用TLS，如果该应用程序未明确验证证书，则TLS被破坏。
虽然从理论上讲，对SSL密码学的攻击主要是理论上的，但从我的PoV来看，它仍然足够强大，几乎可以用于所有目的，而且将持续很长时间。
另一端的数据实际上是做什么的？例如。如果它的数据非常敏感，甚至是信用卡数据，则您不希望它在浏览器的缓存或历史记录等中显示。
可以在安全的SSL通道和非SSL通道之间共享Cookie（因此可以进行身份​​验证）安全的HTTP通道-除非明确标记为“安全”属性。

那么，答案是否更短？是的，SSL可以足够安全，但是（与大多数情况一样）它取决于您的使用方式。 :)

#2 楼

这里有一些问题，主要的是身份验证。两端都需要确保他们正在与合适的人或机构交谈，以阻止中间人攻击。在您的终端上，至关重要的是，使用用户浏览器信任的SSL证书。通过这样做，用户的浏览器可以确保它确实在与正确的站点通信。建立连接后，您可以确保一直与该用户通话，并且连接已加密，即可以防止窃听。

另一个方向的身份验证（即确保您正在与真实用户交谈）通常在应用程序级别的SSL协议之外通过用户​​名/密码，openID或其他某种形式进行处理凭证。

作为最后一点，应该提到的是，在SSL连接握手期间，客户端和服务器同意使用密码套件，并且客户端可以假装仅执行“空加密”，即不对任何加密进行加密。数据。如果您的服务器同意该选项，则连接使用SSL，但是数据仍未加密。实际上这不是问题，因为服务器实现通常不提供空密码作为选项。

#3 楼

除了AviD列出的内容以外，SSL的安全性仅与将您定向到该服务器的DNS基础结构以及通信路径中的任何公司代理一样安全。

如果DNS基础结构被黑客入侵（缓存中毒） ，等等），那么攻击者可能会使您的用户遭受许多攻击。

为减轻这种情况，请查看SSL证书的“发行者”。如果SSL连接通过代理进行，则发行者将是代理的。如果通过直接连接，则会看到相关的公共信任的CA。

[更多信息]

企业HTTPS代理负责管理连接在Web浏览器和Proxy（其IP地址出现在您的Web服务器日志中）之间。在那种情况下，Web内容（也是HTTPS密码）将被解密，然后在公司代理处重新加密并呈现给您的服务器。

取决于谁在管理代理以及如何使用其日志，从您的角度来看这可能是可接受的，也可能是坏事。完成后，请参见以下链接：


当SSL代理拦截SSL
连接时，它将向客户端提供模拟的
服务器证书
浏览器。客户端浏览器向最终用户发出
安全弹出窗口，因为该浏览器不信任ProxySG使用的
发行者。如果将SSL代理使用的颁发者
证书作为
客户端浏览器的证书存储中的受信任根导入
，则不会出现此弹出窗口。

ProxySG通过其管理控制台使所有已配置的
证书可供下载
。您可以
要求最终用户通过Internet Explorer下载颁发者证书

或Firefox，并在他们选择的浏览器中将其安装为受信任的
CA。这
消除了
模拟证书的证书弹出窗口...


一些公司通过部署根证书（通过GPO到每个工作站）。尽管这只会影响使用Microsoft证书存储的软件。 Firefox和Chrome之类的软件需要进行不同的更新。

#4 楼

由于SSL依赖于证书颁发机构（CA），并且基本上任何组织都可以成为CA，因此使用伪造但CA签名的证书的中间人攻击始终是可能的。因此，尽管SSL相对于完全不加密仍是一个巨大的进步，但由于CA系统损坏，其安全性被高估了。在这方面，自签名证书与任何CA签名证书一样安全，但是浏览器将其标记为可疑。

#5 楼

SSL是非常安全的，尽管如果您在未加密的行上运行ANY页面，则有人可以窃取其会话cookie。如果可以的话，我将使站点成为全SSL。或者可能使cookie仅发送加密连接，并且具有不特定于该用户的不安全公共页面。

#6 楼

仍然存在中间人攻击的可能性，在您的情况下，这是用户连接到声称是您的站点的第三方，然后转发请求。当然，精明的用户应该注意到缺少SSL连接或错误的证书，但是大多数用户并没有打开电源并被挂锁图标所欺骗。 SSL本身，只是要注意的一点。您可以放心地假设，没有人能够窃听您的站点和连接源之间的SSL连接。但是，您不能确保连接的来源确实是用户。

#7 楼

由于SSL会加密传输，因此无法窃听任何数据（因为证书是受信任的）。 ，您只需要SSL连接就可以验证您的用户身份（让他们将加密的用户/密码对发送给您的服务器），然后当您发送回cookie时，您应该意识到它很容易被拦截（例如，如果您的用户处于不受保护的无线连接上。）

最近的FireSheep电视剧就是关于此的。

#8 楼

不会。流量分析仍然可以告诉别人很多信息。


流量分析是拦截和检查消息以从通信模式中推断信息的过程。即使消息已加密且无法解密，也可以执行此操作。通常，观察到的消息数量越多，甚至拦截和存储的消息数量越多，可以从流量中推断出更多的消息。 -攻击者对通信的内容不应抱有高度的信心。

，假设，


，攻击者知道您的协议，攻击者知道与谁通信的人
攻击者无法解密消息。
您不会在很多无意义的流量（chaff）中掩盖您的真实流量

攻击者可能会告诉无论您什么时候醒着，什么时候睡着了，无论使用哪种协议，并且根据所使用协议的性质，都可以了解更多信息。


如果您的协议是很简单：


要发射核子时，您会发送一条消息“在...处发射核子”
不发射消息时，您不会发信息想要发射任何核武器。

不能解密y的窃听者我们的数据可以仅通过您要发射核武器的消息来确定，尽管可能不向谁发射。


如果您的协议较复杂，请执行以下操作：


您要书。
我将内容发送给您。

攻击者可能无法分辨谁在阅读“战争与和平”与“阿特拉斯耸耸肩”但可以完全根据消息的大小来区分他们是否正在阅读前者与卡夫卡55页小说《变形记》中的一部。

#9 楼

SSL执行两项基本任务：身份验证和加密。

身份验证是通过证书颁发机构（CA）进行的。浏览器随附用于CA签名密钥的SSL证书列表。 CA签署描述实体公钥的证书。例如，如果我拥有Google.com，我将向Verisign证明这一点，他们将在一段时间内签署我的证书。 CA出现的问题会签署他们不应该签署的证书。当有人假装拥有另一个域，获取的通配符证书范围太广，或者只是XKCD使得CA发行恶意文件（可能是政府）时，就会发生这种情况。我们已经看到了上述所有情况的实例，但是这种情况非常罕见。您可以（出于讨论目的）确信证书匹配的站点。通常情况下，该连接是加密的。这会阻止任何人读取您的数据。

SSL证书非常复杂，并且存在许多针对SSL实现的攻击。 SSL可以有效地做的是，当您在GMail上检查电子邮件时，阻止我查看本地星巴克的流量。它不能做的是阻止我使用MITM攻击，在这种情况下，我无需SSL就将所有内容中继给您，并且没有设置您的客户端来困扰您从未启动加密会话的事实。

#10 楼

假设您使用的是SSL 3.0和强加密，则不计算其他人关于其他潜在问题的各种答案，这应该是安全的。

使用较旧的ssl协议（2.0）或使用弱加密密钥可能会打开您将面临漏洞。

#11 楼

SSL通常通过提供以下功能来提高安全性：


服务器身份验证（用户知道他们正在与“正确的”站点对话）
数据完整性（用户和服务器知道流量是不会在途中被修改）
（可选，但通常是）数据隐私（用户和服务器知道在途中未拦截流量）
（可选，但很少见）客户端身份验证，如果客户端也有一个证书

本质上只有两种类型的SSL证书：服务器证书（始终涉及）和客户端证书（可选）。

这只是一个草图，并且有许多if，ands和buts。在最典型的情况下，即基于浏览器的SSL，在很多情况下都可以破坏该方案而不会破坏密码或协议，而只是依靠用户做错事（即忽略浏览器警告并以任何方式连接）。网络钓鱼攻击也可以通过将用户发送到伪造的受SSL保护的站点来工作，该站点在所有方面都类似于真实的URL站点，但实际上与URL相似。因为它们至少允许安全的通信，尽管远非万无一失。

#12 楼

当某人使用SSL连接到我们的服务
（https）并提交了正确的身份验证数据时，通过此线路传输所有敏感数据是否安全
，还是可能仍然存在窃听？伪造的中间站点，无论是通过Web欺骗/超链接欺骗，还是通过提供无效证书并消除浏览器警告并继续进行连接。您可以执行其他操作（除了可以教育用户，如果可以的话，请认真对待SSL警告）。

#13 楼

当您不使用SSL时，可以轻松拦截所有通信-唯一需要做的就是启动数据包嗅探器（即Wireshark）。知道您要发送的内容。基本上，它用于保护密码和私人内容免遭拦截。您显然不希望其他人阅读您的私人电子邮件，对吗？
对于Google搜索，他们只是为了隐藏人们的要求而已。这是因为一些政府对此太好奇了。

SSL如何提高安全性？它本身不是。加密（SSL密钥）和PKI（公共密钥基础结构）的组合-主要是证书。好，问题是如何。一方面，它确保了您的通信渠道的安全（请参见上文），另一方面，它确保了您与合法企业的交流-认证服务器。因此，该通道是安全且受信任的。

有很多SSL证书，因为有很多PKI服务。基本上，不同的服务需要不同类型的SSL证书。因此，存在用于代码签名，电子邮件加密和签名的证书以及与服务器身份验证有关的证书。

#14 楼

简短的答案是否定的。
更长的答案：上面的答案加上以下内容的集：如果他们获得了服务器机密密钥（例如NSA和National Security Letters），仍然可以对其进行解密。
当我使用Chrome访问gmail.com时，请参见下图。

查看带有SHA1的文本RC4_128，以进行消息认证ECDHE_ECDSA。内容为：


服务器提供带有SHA摘要的SSL信道RC4_128b
在此隧道内，每条消息均使用黄道曲线加密，其中使用Diffie-Helman函数导出密钥并进行签名使用数字签名算法的Eecliptic Curves密码进行加密

换句话说，即使某人拥有SSL服务器的私钥，邮件也已使用临时密钥进行了加密，这些临时密钥在使用后很快就会从内存中丢弃。 NSA祝您好运！

#15 楼

@Vladimir认为http://en.wikipedia.org/wiki/Forward_secrecy是可取的，但是细节有误。服务器从浏览器提供的密码套件中选择该密码套件。 “使用SHA1的RC4_128加密进行消息身份验证”确实使用RC4 128位加密和HMAC-SHA-1完整性检查。 （直到最近才使用SSL / TLS的密码套件名称说SHA，但它们的意思是SHA-1，实际上是HMAC-SHA-1。）“ ECDHE_ECDSA作为密钥交换机制”不适用于单个消息，它是（大部分）在会话开始时发生一次握手：ECDHE在临时模式下使用Diffie-Hellman的Elliptic Curve变体（加上一些此处不重要的附加步骤）来创建用于加密和HMAC的会话密钥；而ECDHE密钥交换（仅）由“数字签名算法”的“椭圆曲线”变体签名。 （您永远不能直接用DH或ECDH加密任何东西，它们只会做密钥或其他小秘密协议。）

#16 楼

对用户安全还是对您安全？假设发生中间人攻击。攻击者设法捕获用户的流量，冒充您成为用户，并冒充您。这种攻击通常会失败，因为提供给用户的证书将不正确。例如，攻击者为用户提供了您网站的自签名证书。但是，如果用户愚蠢的行为，他们可能会接受该自签名证书。因此，现在攻击者可以读取和修改用户与您之间的所有流量，据我所知，您无法检测到此流量。

因此，如果侦听和修改流量伤害了用户，那实际上是他们自己的错，也是他们自己的问题。而且您也无法完全阻止它，因为MITM可以完全切断您的权限，而只是与假装自己的用户交谈。但是，如果侦听和更改流量会伤害您，那么您必须信任用户不要愚蠢，或者更好地对用户进行身份验证（用户将需要证书，并且可以通过MITM不能进行的方式进行检查。假）。

#17 楼

我认为这里的人不明白这个问题：

如果您的线路不安全，并且通过该线路成功建立了SSH / SSL连接，他现在会问是否可以安全地假设这行是“安全的”，未加密的数据可以与加密的连接（例如，在普通情况下，而不是在加密的SSL / SSH连接内部）一起传递。

我不会。在这种情况下，可能会有一个被动的窃听者，它会忽略加密的数据并保存未加密的数据。

但是，您可以确定没有主动的窃听器（MITM），这意味着您可以安全地建立未经身份验证的SSL / SSH连接具有与已验证行相同的源/目标。
这没有提供MITM某些连接器的选择性窃听器，但是，窃听者无法知道您是否要验证连接，因此他不知道与MITM的哪个连接可逃避检测。如果他是MITM，则MITMer会选择MITM的所有Connections，并希望人们简单地单击所有身份验证对话框。您也可以安全地将SSH客户端从123.123.123.123连接到24.24.24.24，而无需相互验证SSH指纹，前提是您可以信任对方NAT路由器或防火墙背后的所有内容。通常意味着，窃听者只是随机地将MITM连接随机化并希望不会被检测到，因此存在很小的风险，所以既然您已经具有到目标IP的经过身份验证的连接，为什么不使用该经过身份验证的连接来相互验证SSH指纹？简单易行，只需在SSL受保护的网站上发布正确的SSH指纹即可！

#18 楼

如果客户端信任CA，则即使是使用TLS的HTTPS的最现代版本，也可以通过MitM（例如为此配置的Juniper设备）轻松拦截。在那种特殊情况下，它是不安全的。