首页 文章

SSL如何真正起作用?

提问于
浏览
118

SSL如何工作?

证书安装在客户端(或浏览器?)和服务器(或Web服务器?)上的哪个位置?

当您将URL输入浏览器并从服务器获取页面时,信任/加密/身份验证过程如何开始?

HTTPS协议如何识别证书?当所有信任/加密/认证工作的证书是什么时,为什么HTTP不能使用证书?

4 回答

  • 128

    注意:我非常仓促地写了我的原始答案,但从那时起,这已成为一个相当受欢迎的问题/答案,所以我对它进行了一些扩展并使其更精确 .

    TLS功能

    “SSL”是最常用于引用此协议的名称,但SSL特别指的是Netscape在90年代中期设计的专有协议 . “TLS”是基于SSL的IETF标准,因此我将在答案中使用TLS . 现在,几乎所有网络上的安全连接都使用TLS而不是SSL .

    TLS有几个功能:

    • 加密应用程序层数据 . (在您的情况下,应用程序层协议是HTTP . )

    • 向客户端验证服务器 .

    • 将客户端验证到服务器 .

    #1和#2很常见 . #3不太常见 . 你似乎专注于#2,所以我会解释那部分 .

    身份验证

    服务器使用证书向客户端验证自身 . 证书是一团数据[1],其中包含有关网站的信息:

    • 域名

    • 公钥

    • 拥有它的公司

    • 何时发出

    • 到期时

    • 是谁发行的

    您可以使用证书中包含的公钥来实现机密性(上面的#1),以加密只能由相应私钥解密的消息,这些私钥应该安全地存储在该服务器上 . [2]让我们称这个密钥对KP1,以便我们以后不会混淆 . 您还可以验证证书上的域名是否与您访问的站点匹配(上面的#2) .

    但是,如果攻击者可以修改发送到服务器和从服务器发送的数据包,如果该攻击者修改了您提供的证书并插入了自己的公钥或更改了任何其他重要细节,该怎么办?如果发生这种情况,攻击者可以拦截和修改您认为安全加密的任何邮件 .

    为了防止这种攻击,证书由其他人的私钥加密签名,以便签名可以由具有相应公钥的任何人验证 . 让我们调用这个密钥对KP2,以明确这些密钥与服务器使用的密钥不同 .

    证书颁发机构

    那么谁创造了KP2?谁签了证书?

    证书授权机构过度简化了一点,创建了KP2,他们销售使用私钥为其他组织签署证书的服务 . 例如,我创建了一个证书,我向Verisign这样的公司付款,用他们的私钥签名 . [3]由于Verisign没有人可以访问此私钥,因此我们都无法伪造此签名 .

    我个人如何获得KP2中的公钥以验证签名?

    好吧,我们已经看到证书可以保存公钥 - 计算机科学家喜欢递归 - 那么为什么不将KP2公钥放入证书中并以这种方式分发呢?起初这听起来有点疯狂,但实际上这正是它的工作原理 . 继续Verisign示例,Verisign生成一个证书,其中包含有关他们是谁,允许他们签署什么类型的事物(其他证书)以及他们的公钥的信息 .

    现在,如果我有Verisign证书的副本,我可以使用它来验证我想访问的网站的服务器证书上的签名 . 容易,对吧?!

    好吧,不是那么快 . 我必须从某个地方获得Verisign证书 . 如果有人欺骗Verisign证书并将自己的公钥放在那里怎么办?然后他们可以在我们开始的地方重建服务器's certificate, and we'上的签名:一个中间人攻击 .

    证书链

    继续以递归方式思考,我们当然可以引入第三个证书和第三个密钥对(KP3)并使用它来签署Verisign证书 . 我们称之为证书链:链中的每个证书都用于验证下一个证书 . 希望你已经可以看到这种递归方法只是乌龟/证书 . 它停在哪里?

    由于我们无法创建无限数量的证书,证书链显然必须停在某处,这是通过在自签名的链中包含证书来完成的 .

    当你从脑袋里捡起脑部物质时,我会暂停一会儿 . 自签名?

    是的,在证书链的末尾(a.k.a . “root”),会有一个证书使用它自己的密钥对来签署自己 . 这消除了无限递归问题,但它不能解决身份验证问题 . 任何人都可以创建一个自签名的证书,上面写着任何东西,就像我可以创建一个假的普林斯顿文凭,说我在政治,理论物理和应用对接的三个主要部分,然后在底部签署我自己的名字 .

    解决此问题的[有点令人兴奋的]只是选择一些您明确信任的自签名证书 . 例如,我可能会说,“我相信这张Verisign自签名证书 . ”

    有了明确的信任,现在我可以验证整个证书链 . 无论链中有多少证书,我都可以将每个签名一直验证到根目录 . 当我到达root时,我可以检查该根证书是否是我明确信任的证书 . 如果是这样,那么我可以信任整个链条 .

    授予信托

    TLS中的身份验证使用授予信任的系统 . 如果我想雇用一名汽车修理工,我可能不相信任何我发现的随机技工 . 但也许我的朋友要为特定的机械师担保 . 因为我相信我的朋友,所以我可以相信那个技师 .

    当您购买计算机或下载浏览器时,它会附带几百个明确信任的根证书 . [4]拥有和运营这些证书的公司可以通过签署证书将这种信任授予其他组织 .

    这远非一个完美的系统 . 有时,CA可能会错误地颁发证书 . 在这些情况下,可能需要撤销证书 . 撤销是棘手的,因为颁发的证书将始终是加密正确的;需要一个带外协议来找出哪些以前有效的证书已被撤销 . 在实践中,其中一些协议不是很安全,许多浏览器无论如何都不检查它们 .

    有时整个CA都会受到损害 . 例如,如果您要进入Verisign并窃取其根签名密钥,那么您可以欺骗世界上的任何证书 . 请注意,这并不重要 . 我的证书仍然可以使用威瑞信的受感染签名密钥伪造 .

    这不仅仅是理论上的 . 它发生在野外 . DigiNotar was famously hacked然后破产了 . Comodo was also hacked,但莫名其妙地,他们至今仍在营业 .

    即使CA没有直接受到攻击,该系统也存在其他威胁 . 例如,政府使用法律强制迫使CA签署伪造证书 . 您的雇主可以在您的员工计算机上安装自己的CA证书 . 在这些不同的情况下,您希望“安全”的流量实际上对控制该证书的组织完全可见/可修改 .

    已经提出了一些替换,包括ConvergenceTACKDANE .

    尾注

    [1] TLS证书数据根据X.509 standard格式化 . X.509基于ASN.1("Abstract Syntax Notation #1"),这意味着它不是二进制数据格式 . 因此,必须将X.509编码为二进制格式 . DER and PEM是我所知道的两种最常见的编码 .

    [2]在实践中,协议实际上切换到对称密码,但这是一个与您的问题无关的细节 .

    [3]可以预测,CA实际上会在签署证书之前验证您的身份 . 如果他们没有这样做,那么我可以为google.com创建一个证书并要求CA签名 . 凭借该证书,我可以与google.com Build 任何“安全”连接 . 因此,验证步骤是CA操作中非常重要的因素 . 遗憾的是,目前还不十分清楚这个验证过程对全球数百个CA的严格程度 .

    [4]见Mozilla的list of trusted CAs .

  • 2

    HTTPS是 HTTPSSL(Secure Socket Layer) 的组合,用于在客户端(浏览器)和Web服务器之间提供加密通信(此处托管应用程序) .

    Why is it needed?

    HTTPS加密通过网络从浏览器传输到服务器的数据 . 因此,没有人可以在传输过程中嗅探数据 .

    如何在浏览器和Web服务器之间 Build HTTPS连接?

    • 浏览器尝试连接到https://payment.com .

    • payment.com服务器向浏览器发送证书 . 此证书包含payment.com服务器的公钥,以及此公钥实际属于payment.com的一些证据 .

    • 浏览器验证证书以确认它具有payment.com的正确公钥 .

    • 浏览器选择随机的新对称密钥K用于连接到payment.com服务器 . 它在payment.com公钥下加密K.

    • payment.com使用其私钥解密K.现在浏览器和支付服务器都知道K,但没有其他人知道 .

    • 无论何时浏览器都想向payment.com发送内容,它会在K下对其进行加密; payment.com服务器在收到后对其进行解密 . 任何时候payment.com服务器想要发送给你的东西浏览器,它在K下加密它 .

    此流程可以通过下图表示:
    enter image description here

  • 42

    我写了一篇小博客文章,简要讨论了这个过程 . 请随便看看 .

    SSL Handshake

    一个小片段如下:

    “客户端通过HTTPS向服务器发出请求 . 服务器发送其SSL证书公钥的副本 . 在使用其本地可信CA存储库验证服务器的身份后,客户端生成秘密会话密钥,使用服务器的公钥对其进行加密服务器使用其私钥解密秘密会话密钥,并向客户端发送确认 . Build 安全通道 . “

  • 0

    Mehaase已经详细解释了它 . 我将把这2美分加到这个系列中 . 我有很多关于SSL握手和证书的博客文章 . 虽然大多数都围绕IIS Web服务器,但该帖子仍然与SSL / TLS握手有关 . 这里有一些供您参考:

    不要将CERTIFICATES和SSL视为一个主题 . 将它们视为两个不同的主题,然后尝试查看它们的工作原理 . 这将有助于您回答这个问题 .

    Establishing trust between communicating parties via Certificate Store

    SSL / TLS通信仅基于信任 . Internet上的每台计算机(客户端/服务器)都有一个它维护的根CA 's and Intermediate CA'列表 . 这些是定期更新的 . 在SSL握手期间,这用作 Build 信任的参考 . 例如,在SSL握手期间,当客户端向服务器提供证书时 . 服务器将尝试确认颁发证书的CA是否存在于其CA列表中 . 当它无法做到这一点时,它声明它无法进行证书链验证 . (这是答案的一部分 . 它也会查看 AIA . )客户端也对它在Server Hello中收到的服务器证书进行类似的验证 . 在Windows上,您可以通过PowerShell查看客户端和服务器的证书存储 . 从PowerShell控制台执行以下操作 .

    PS证书:> ls位置:CurrentUser StoreNames:{TrustedPublisher,ClientAuthIssuer,Root,UserDS ...}位置:LocalMachine StoreNames:{TrustedPublisher,ClientAuthIssuer,Remote Desktop,Root ...}

    像Firefox和Opera这样的浏览器不依赖于底层操作系统来进行证书管理 . 他们维护自己独立的证书商店 .

    SSL握手使用对称和公钥加密 . 默认情况下会发生服务器验客户端身份验证是可选的,取决于服务器 endpoints 是否配置为对客户端进行身份验证 . 请参阅我的博文,因为我已经详细解释了这一点 .

    Finally for this question

    HTTPS协议如何识别证书?当所有信任/加密/认证工作的证书是什么时,为什么HTTP不能使用证书?

    Certificates 只是一个文件,其格式由X.509 standard定义 . 它是一个电子文档,证明了通信方的身份 . HTTPS = HTTP + SSL 是一个协议,它定义了2方如何相互通信的指导方针 .

    MORE INFORMATION

    • 为了了解证书,您必须了解证书,并阅读有关证书管理的信息 . 这些很重要 .

    • 一旦理解了这一点,然后继续进行TLS / SSL握手 . 您可以参考RFC . 但它们是定义指南的骨架 . 有几个博客帖子,包括我的详细解释 .

    如果完成上述活动,那么您将对证书和SSL有一个公平的理解 .

相关问题