使用wireshark分析HTTPS作业流程的建立

使用wireshark分析HTTPS步骤建立摘要:https步骤一、概要为了网站和用户安全性，现在很多网站全部是https，大家全部知道tcp经过三次握手建立连接，而且还有很多同学对https连接建立步骤不太明白，包含我自己，经过借助于wireshark这种抓包工具，我们能够尝试着了解一下大约步骤。（图1）本图是用户端（03）访问服务端（5）经过wireshark抓包显示出来双方交互数据，访问是经过https访问服务器上一台nginx服务器服务。请关注第一列No。下文中很多时候会用no表示一次交互。图中能够很显著看出tcp三次握手和以后TLS加密步骤建立。二、tcp三次握手经过步骤图能够看出（也能够看图119368到19370这三个编号），首先用户端向服务端提议一个SYN请求，序号(Seq)为0，确定号（ACK）也为0，这代表是此次是由用户端提议首次请求。此次请求数据长度为0然后服务端给用户端响应，此时服务端Seq也是0，值得是服务端第一回应，而且给用户端说，你请求我已经收到了（ACK=1），最终返还给用户端以后，用户端序号+1，而且对服务端响应做出确定，最终回给服务端，此时ACK=1，Seq=1tcp握手过程建立成功。三、ssl连接建立经过以上能够看出，SSL也是建立在TCP基础上，经过tcp三次握手，接下来才是加密信道建立。用户端和服务端建立安全连接大致经过以下多个步骤用户端：ClientHello服务端：ServerHello，Servercertificate，ServerExchange，ServerHelloDone用户端：clientExchange用户端：ApplicationData服务端：NewSession服务端：ApplicationData接下来看这多个步骤中具体每一个步骤传输内容ClientHelloclient首先给服务端打招呼，对服务端说hello应用层没什么尤其用户端向服务端发送202个字节数据，而且用户端此时seqnum为1，tcp三次握手已经经过了，所以用户端acknum确定是服务端tcp最终一次信息。因为这次发送长度是202个字节，所以给服务端说，下一个字节序列号是从203开始。标志位为ACK和PSH不过这次多了一个SecureSocketlayer层。协议使用时候，用是HandshakeProtocol，给服务端发消息ClientHello具体信息以下：SecureSocektslayer层使用是版本是TLS

1.0HandShakeType类型，是用户端打招呼clienthelloHandShakeprotocol协议使用是TLS1.2发送信息还有用户端在当地生成随机码（Random）然后用户端申明自己所支持加密套件（CipherSuites）这个用户端支持15种加密套件加密套件中表明了使用对称加密算法，非对称加密算法，摘要算法和使用是TLS或是SSL还有部分其它信息第一行指明是否进行了压缩和使用压缩算法，第二行null表明未进行压缩，和选择相关压缩算法或压缩工具剩下就是部分扩展字段了总结下来，用户端向服务端第一次打招呼（clientHello）时候实际上关键发送了以下关键信息用户端随机数用户端所支持加密套件和用户端和服务器之间sessionId接下来就是服务端对用户端Hello第一次回应，也就是编号19372能够看到服务端使用是443端口，序列号（Sequencenumber）也是1，而且回应用户端说我已经确定收到你202个自己数据（203-1），Flags表明此次是服务端反馈给用户端请求应答（蓝色文字也写出来了，这是一个队19371编号应答）从图1能够看出这是一个TCP连接ServerHello接下来不等用户端反应，服务端又给用户端发送了19373数据，而这个数据就是使用了TLS1.2协议了。摘要信息中说明了这是服务端hello,Serverhello,服务端秘钥交换，服务端hellodone。接下来看服务端发过来具体全部有什么。传输控制层（transmissioncontrolprotocol）和上面一样，关键是部分Flags，端口和数据长度确实定等等，关键看一下安全套接字层东西（SecureSocketsLayer）中东西。经过上图，能够看出服务端关键返回四种内容。ServerHello服务端回应用户端hello信息Certificate

服务端证书ServerkeyExchange服务器秘钥交换ServerHelloDone服务器信息发送完成具体看一下各个Recordlayer中具体内容ServerHello在ServerHello中，服务器返回服务端随机数，所选择TLS版本，和服务器最终选择用户端和服务端交互加密套件（TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xc030)），最终选择加密套件是RSA非对称加密算法和AES对称加密算法，用是SHA384做摘要，注意，这个值必需是用户端发给服务端列表中选出来。实际上假如用户端只能支持版本和安全性比较低加密套件，这么服务端选择和用户端交互时候也被迫只能使用低版本加密套件，其安全性就会降低。除了以上这些，服务端ServerHello时发送回来还有是否使用了压缩和部分其它扩展字段CertificateServerHello以后，服务端会发送公钥证书给用户端Certificates(953bytes)CertificateLength:950Certificate:308203b23082029aa003000d06092a864886...(id-at-commonName=.com,id-at-organizationName=JD,id-at-stateOrProvinceName=BJ,id-at-countryName=CN)signedCertificateversion:v3(2)serialNumber:1signature(sha256WithRSAEncryption)AlgorithmId:1.2.840.11351(sha256WithRSAEncryption)issuer:rdnSequence(0)rdnSequence:7items(pkcs-9-at-emailAddress=,id-at-commonName=wangtengfei,id-at-organizationalUnitName=section,id-at-organizationName=JD,id-at-localityName=BJ,id-at-stateOrProvinceName=BJ,id-at-countryName=CN)RDNSequenceitem:1item(id-at-countryName=CN)RDNSequenceitem:1item(id-at-stateOrProvinceName=BJ)RDNSequenceitem:1item(id-at-localityName=BJ)RDNSequenceitem:1item(id-at-organizationName=JD)RDNSequenceitem:1item(id-at-organizationalUnitName=section)RDNSequenceitem:1item(id-at-commonName=wangtengfei)RDNSequenceitem:1item(pkcs-9-at-emailAddress=)validitynotBefore:utcTime(0)utcTime:16-11-2206:38:18(UTC)notAfter:utcTime(0)utcTime:17-11-2206:38:18(UTC)subject:rdnSequence(0)rdnSequence:4items(id-at-commonName=.com,id-at-organizationName=JD,id-at-stateOrProvinceName=BJ,id-at-countryName=CN)RDNSequenceitem:1item(id-at-countryName=CN)RDNSequenceitem:1item(id-at-stateOrProvinceName=BJ)RDNSequenceitem:1item(id-at-organizationName=JD)RDNSequenceitem:1item(id-at-commonName=.com)subjectPublicKeyInfoalgorithm(rsaEncryption)AlgorithmId:1.2.840.1135(rsaEncryption)subjectPublicKey:308a028100be56d1a2b725cf5d6fa1997c83b221...modulus:0x00be56d1a2b725cf5d6fa1997c83b221de8452658b1e7c86...publicExponent:65537extensions:4itemsalgorithmIdentifier(sha256WithRSAEncryption)AlgorithmId:1.2.840.11351(sha256WithRSAEncryption)Padding:0encrypted:41bfd96f86c44a731d6ff7af7e9e666703c744aa8c691d38...1中有证书指纹，和证书署名信息Certificate:308203b23082029aa003000d06092a864886...(id-at-commonName=.com,id-at-organizationName=JD,id-at-stateOrProvinceName=BJ,id-at-countryName=CN)看以看出，这个证书是针对.com这个域名签发，然后就是部分签发机构信息等。2证书过期时间（validity），能够看出证书过期时间为1年，从11月22日6点38分18秒(notBefore)到从11月22日6点38分18秒(notAfter)3证书签发主体(subject)4公钥证书key.当然这证书下放以后，服务端会把签发证书hash也发送过来，以证实此证书在传输过程中没有被修改。能够看出使用sha256算法做摘要。证书我们也能在浏览器中用可视化方法查看。我会把证书导出，能够自行查看接下来就是秘钥交换了ServerkeyExchange这个就是服务端公钥keyHelloDone最终就是服务端发送一个HelloDone标示此次内容全部发放完成。总结一下在用户端向服务端打招呼以后，服务端关键发送了那些内容。首先是发送服务端自己随机数给用户端，然后下发服务端公钥证书和下发公钥key，最终服务端用hellodone标示此次内容全部发送完成。以上发送过程我们全部能够看得到，也就是说在这个过程中，用户端和服务端交互使用全部还是明文。ClientkeyExchange用户端接收到服务端这些证书信息以后，解析来会进行回应服务端。能够看19374编号查看传输层，传输层中明确写明了这是对19373一个回应。关键还是查看安全套接字层，具体来看回应是什么

关键包含了以下多个方面Clientkeyexchange包含了pre-mastersecret。这是在握手过程中生成第三个随机数。分别是clienthello阶段用户端随机数，然后在serverhello阶段服务端随机数。这一次是用户端接收到服务端证书以后，生成一个预加密因子（供对称加密使用）。Changecipherspec用户端通知服务端接下来就要使用加密方法来进行通信了。然后在19375中，用户端发送给服务端一段加密后内容（就是在这一步，数据交互从明文开始转化为密文），而且把此次会话信息中全部细节做摘要发给服务端，以证实在此次过程中双方达成一致，未受到其它干扰服务端确定用户端加密请求然后服务端会在19376和19377中，服务端对用户端发送内容进行确定（19374），提供新SessionTicket，然后发送了一段内容，而且对全部握手内容做摘要，发