我有一个基本的了解，HTTPS使用某种唯一的标识代码在用户和服务器之间创建安全的连接。但是，如果服务器将该代码（或其任何内容）发送给用户，那么该代码是否不会被截取，从而使整个HTTPS像HTTP一样容易受到攻击？
我是这个领域的新手，并且对它的工作方式很感兴趣。当前有关堆栈溢出的答案无法提供完整的答案。
我不确定是否可以说关于SSL的工作原理在Stack Overflow上没有任何答案：https://stackoverflow.com/search?q=how+does+ssl+work
Cookie在HTTPS上的工作方式与在HTTPS上的工作方式相同。 HTTPS只是HTTP，但是服务器和客户端使用“共享秘密”对称加密密钥来加密和解密它们交换的数据，从而使第三方无法截获和读取通信。
话虽这么说，并且在很大程度上同意从Wikipedia开始阅读的建议，但我为什么不通过简短地解释一下来对此做一个适度的损害呢？
首先，“ SSL”现在正式过时，因为SSLv3中的POODLE漏洞将永远不会被修复。 SSL（安全套接字层）已由TLS（传输层安全性）继承，尽管已成为安全HTTP（HTTPS）的术语，但确实有些不准确，它实际上已成为通用名称。
仍然，SSL和TLS都使用相同的基础技术和一般思想。
涉及多种技术，所有技术都很复杂，而且它们之间的相互作用也很复杂。
但是这里是要点，简而言之。
SSL / TLS基本上依赖于public/private key asymmetric encryption，以便安全地交换共享机密-短暂的（一次性的，短期的）symmetric encryption密钥，只有服务器和客户端才知道，客户端和然后服务器使用该服务器加密从此以后交换的消息。
非对称加密本身就是一个大而科学的话题。
āˈsimətrē /
名词：某物的各部分或各方面之间缺乏平等或对等；缺乏对称性。
非对称加密利用成对的私钥和公钥，它们从数学上非常大的，与数学相关的素数数学上得出。
加密是不对称的，因为如果使用“专用”密钥对邮件进行加密，则只能使用“公用”密钥对邮件进行解密，反之亦然。
因此，保持私钥的私密性绝对重要。公用密钥可以（实际上是is）发布给全世界
TLS使用非对称加密和握手协议来创建和交换仅服务器和客户端已知的对称会话加密密钥。
非对称加密比对称加密慢一个数量级，这使其不适合加密用于实时通信的数据。使它不适合用于双向通信的数据加密的另一件事是，拥有服务器的私钥加密的任何东西都可以被拥有公钥的任何人解密。根据定义，这是Everybody。
因此，做出了故意过分简化的残酷行为；握手协议基本上允许客户端发送加密的质询，只有服务器才能解密，然后服务器可以使用其私钥对该质询进行签名并返回。客户端既知道发送的挑战，又知道如何使用服务器的公钥验证服务器的签名。一旦客户端和服务器对自己的通信没有被篡改感到满意，他们就可以安全地交换临时对称加密密钥。可以组合一些步骤以减少往返次数，并且该协议的不同版本在细节上有所不同...（会过分简化，请记住）。
有许多可用的加密协议和密钥长度，并且在密钥交换期间协商了这些细节。我们只说客户端和服务器同意使用256位密钥进行AES加密。
因此，一旦客户端和服务器安全地交换了256位密钥（它们协商的大小），他们就可以随意使用该密钥以及他们也协商的AES算法安全地加密和交换数据。没有任何一方拥有该临时加密密钥，因此，任何一方都无法解密他们交换的数据。
对称加密比非对称加密快得多。因此，加密/解密大数据传输的性能影响实际上是不相关的。
HTTPS的昂贵部分在于初始协议握手和密钥交换，因为它需要多次往返和几轮超级昂贵的非对称加密。因此，当客户端和服务器为多个请求重用同一连接时，HTTPS通信将极大地受益。有关此信息，请查看SPDY协议。
最后，您应该研究forward secrecy and/or perfect forward secrecy。前向保密的做法是在握手过程中交换临时公共/专用密钥对，然后使用该临时公共/专用密钥对进行握手并交换私有对称密钥，并迅速丢弃临时私有/公共密钥对。这样做是为了防止将来如果Web服务器的私钥受到破坏，可以防止对捕获的HTTPS会话进行重放和解密。
有些协议允许两方到达一个共享的加密密钥，即使它们之间的所有通信都是明确的。
查看the Wikipedia article SSL握手过程中如何发生。
他们拥有此会话密钥后，将用于对有效载荷消息进行加密。