资源

HTTPS为什么安全 &分析 HTTPS 连接建立全过程 https://wetest.qq.com/lab/view/110.html
RFC: The Transport Layer Security (TLS) Protocol 1.2 1.3

https://en.wikipedia.org/wiki/Transport_Layer_Security

HTTPS解决的问题

非对称加密相对安全, 但是极端消耗性能
所以服务端给客户端一个公钥, 客户端用公钥加密一个对称加密的秘钥, 发给服务端
后续通信的内容用这个秘钥进行对称加密

这个过程可能被中间人攻击:

为了解决此问题，我们引入了数字证书的概念。
服务器首先生成公私钥，将公钥提供给相关机构（CA），CA将公钥放入数字证书并将数字证书颁布给服务器，
此时服务器就不是简单的把公钥给客户端，而是给客户端一个数字证书，
数字证书中加入了一些数字签名的机制，保证了数字证书一定是服务器给客户端的。
中间人发送的伪造证书，不能够获得CA的认证，此时，客户端和服务器就知道通信被劫持了。
加入了CA数字签名认证的SSL会话过程如下所示：

浏览器发起握手并接收到证书后，如何确认这个证书就是CA签发的呢？怎样避免第三方伪造这个证书？答案就是数字签名（digital signature）。
数字签名是证书的防伪标签，目前使用最广泛的SHA-RSA（SHA用于哈希算法，RSA用于非对称加密算法）。数字签名的制作和验证过程如下：
1、数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希，生成消息摘要，然后使用CA自己的私钥对消息摘要进行加密。
2、数字签名的校验。使用CA的公钥解密签名，然后使用相同的签名函数对签名证书内容进行签名，并和服务端数字签名里的签名内容进行比较，如果相同就认为校验成功。

SSL/TLS Handshake

      Client                                               Server
      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

link

client hello

Extensions: Server_name
当我们去访问一个站点时，一定是先通过DNS解析出站点对应的ip地址，通过ip地址来访问站点，
由于很多时候一个ip地址是给很多的站点公用，因此如果没有server_name这个字段，server是无法给与客户端相应的数字证书的，Server_name扩展则允许服务器对浏览器的请求授予相对应的证书。

ServerHello

Certificate 即前述的数字证书

Certificate Request

server 如何指明要哪一个 Client Certificate ?
client 如何选择 Client Certificate ?

Upon receiving the Server Hello containing the Client Certificate request & list of Distinguished CA names, the client will perform the following steps:

• The client uses the CA list available in the SERVER HELLO to determine the mutually trusted CA certificates.
• The client will then determine the Client Certificates that have been issued by the mutually trusted Certification Authorities.
• The client will then present the client certificate list to the user so that they can select a certificate to be sent to the user.
• Upon selection, the client responds with a
  • ClientKeyExchange message which contains the Pre-master secret
  • Certificate message which contains the Client certificate(Doesn’t contain the private key).
  • CertificateVerifymessage, which is used to provide explicit verification of a client certificate. This message is sent only if the Client Certificate message was sent. The client is authenticated by using its private key to sign a hash of all the messages up to this point. The recipient verifies the signature using the public key of the signer, thus ensuring it was signed with the client’s private key. Refer RFC 5246 for more details.
• Post this Client & Server use the random numbers and the Pre-Master secret to generate symmetric (or Master) keys which will used for encrypting & decrypting messages for further communication.
• Both respond with ChangeCipherSpec indicating that they have finished the process.
• SSL Handshake stands completed now and both the parties own a copy of the master key which can be used for encryption and decryption.

note:

• On the Client the Client Certificates must have a Private Key. If absent, then the certificate is ignored.
• If the server doesn’t provide the list of Distinguished CA Names in the SERVER HELLO, then the client will present the user with all the client certificates that it has access to.

link

      struct {
          ClientCertificateType certificate_types<1..2^8-1>;
          SignatureAndHashAlgorithm
            supported_signature_algorithms<2^16-1>;
          DistinguishedName certificate_authorities<0..2^16-1>;
      } CertificateRequest;

certificate_authorities A list of the distinguished names [X501] of acceptable certificate_authorities, represented in DER-encoded format. These distinguished names may specify a desired distinguished name for a root CA or for a subordinate CA; thus, this message can be used to describe known roots as well as a desired authorization space. If the certificate_authorities list is empty, then the client MAY send any certificate of the appropriate ClientCertificateType, unless there is some external arrangement to the contrary.

link

抓包展示

更多详细过程见: https://wetest.qq.com/lab/view/110.html

经过代理的连接

https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling
https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/CONNECT

Client Certificate

Your server is asking for a client-side certificate. You need to install a certificate (signed by a trusted authority) on your client machine, and let your program know about it.
Typically, your server has a certificate (with the key purpose set to “TLS server authentication”) signed by either your organization’s IT security or some globally trusted CA. You should get a certificate for “TLS client authentication” from the same source.
If you capture the TLS handshake in Wireshark, you’ll see the ServerHello message followed by a “Client Certificate Request”, to which you reply with a “Client Certificate” message with length 0. Your server chooses to reject this.
https://stackoverflow.com/questions/36284543/ssl-400-no-required-certificate-was-sent

为什么pfx中要带private key

During the SSL/TLS handshake, the server sends its certificate (in clear) and proves to the client that it has the corresponding private key using an authenticated key exchange.
If you want to use client-certificate authentication. It’s not enough to send the client certificate during the handshake: the client must also prove it has the private key. Otherwise, anyone who receives that certificate could clone it.
More specifically, the client has to sign the handshake messages in the Certificate Verify message of the TLS handshake so that the server can verify it against the public key sent in the client certificate.
link

管理client certificate

https://www.digicert.com/kb/managing-client-certificates.htm

Recovering a certificate where the private key is marked as non-exportable
https://damn.technology/recovering-a-certificate-where-the-private-key-is-marked-as-non-exportable
https://docs.microsoft.com/en-us/powershell/module/pkiclient/get-certificate?view=win10-ps
https://stackoverflow.com/questions/22408150/get-thumbprint-of-a-certificate

试了几个命令, 不好使:

$a = Get-Item Cert:\LocalMachine\My\6a1d34c6396c053c7a7a6b30328131ca808a8a6d
Get-ChildItem -Path Cert:\LocalMachine\My |  Where-Object {$_.Thumbprint -match "6a1d34c6396c053c7a7a6b30328131ca808a8a6d"}
$Thumbprint = (Get-ChildItem -Path Cert:\LocalMachine\My |  Where-Object {$_.Thumbprint -match "6a1d34c6396c053c7a7a6b30328131ca808a8a6d"}).Thumbprint -join ';';
Write-Host -Object "My thumbprints are: $Thumbprint";
$Thumbprint = Get-ChildItem -Path Cert:\LocalMachine\My |  Where-Object {$_.Thumbprint -match "6a1d34c6396c053c7a7a6b30328131ca808a8a6d"};
Recovering a certificate where the private key is marked as non-exportable

其他

X.509
https://en.wikipedia.org/wiki/X.509
In cryptography, X.509 is a standard defining the format of public key certificates.

SHA-1
https://en.wikipedia.org/wiki/SHA-1
In cryptography, SHA-1 (Secure Hash Algorithm 1) is a cryptographic hash function which takes an input and produces a 160-bit (20-byte) hash value known as a message digest – typically rendered as a hexadecimal number, 40 digits long.

WCF
https://en.wikipedia.org/wiki/Windows_Communication_Foundation
https://docs.microsoft.com/en-us/dotnet/framework/wcf/getting-started-tutorial
The Windows Communication Foundation (WCF), previously known as Indigo, is a free and open-source runtime and a set of APIs in the .NET Framework for building connected, service-oriented applications.