zoukankan      html  css  js  c++  java
  • TLS握手

    http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

    1994年,NetScape公司设计了SSL协议(Secure Sockets Layer)的1.0版,但是未发布。

    1995年,NetScape公司发布SSL 2.0版,很快发现有严重漏洞。

    1996年,SSL 3.0版问世,得到大规模应用。

    1999年,互联网标准化组织ISOC接替NetScape公司,发布了SSL的升级版TLS 1.0版。

    2006年和2008年,TLS进行了两次升级,分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年TLS 1.2的修订版

     

    http://blog.csdn.net/fw0124/article/details/40983787

    http://blog.csdn.net/liangyihuai/article/details/53098482

    使用如下语法,过滤指定ip的通讯,以及协议类型

    ssl and ip.dst== 24.105.29.76

    ssl一共有11个步骤,但是区分双向认证和单向认证。

    SSL/TLS握手过程可以分成两种类型:

    1)SSL/TLS 双向认证,就是双方都会互相认证,也就是两者之间将会交换证书。
    2)SSL/TLS 单向认证,客户端会认证服务器端身份,而服务器端不会去对客户端身份进行验证。

    我们知道,握手过程实际上就是通信双方协商交换一个用于对称加密的密钥的过程,而且握手过程是明文的。

    Client

    Server

    1 Client Hello  
     

    2 Server Hello
    3 certificate
    4 (server_key_exchange)
    5 (certificate_request)
    6 server_hello_done

    7 (certificate)
    8 client_key_exchange
    9 (certifiate_verify)
    10 change_cypher_spec
    ----finished----
     
      11 change_cypher_spec
    ----finished----

    下面是一个单向认证的截图,风暴英雄和服务器的数据交互

    (5,7,9是跳过的)

    4.1 客户端发出请求(ClientHello)

    第一步  Client Hello

    首先,客户端(通常是浏览器)先向服务器发出加密通信的请求,这被叫做ClientHello请求。

    在这一步,客户端主要向服务器提供以下信息。

    (1) 支持的协议版本,比如TLS 1.0版。  Version

    Version: TLS 1.2 (0x0303)

    (2) 一个客户端生成的随机数,稍后用于生成"对话密钥"。 Random

    这部分由时间和随机数组成。

    Random: 5a18eca2df1b4246ec96ba558213d4eeeebf802a9e7e3470...
    GMT Unix Time: Nov 25, 2017 12:08:02.000000000 China Standard Time
    Random Bytes: df:1b:42:46:ec:96:ba:55:82:13:d4:ee:ee:bf:80:2a:9e:7e:34:70:38:00:76:56:f0:c5:f7:1a

    (3) 支持的加密方法,比如RSA公钥加密。 Cipher Suites

    Cipher Suites (30 suites)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
    Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
    Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
    Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
    Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
    Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
    Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
    Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
    Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
    Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
    Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

    (4) 支持的压缩方法。CompressionMethod

    Compression Methods (1 method)
    Compression Method: null (0)

     4.2 服务器回应(SeverHello)

    第二步   Server Hello

    服务器收到客户端请求后,向客户端发出回应,这叫做SeverHello。

    服务器的回应包含以下内容。

    (1) 确认使用的加密通信协议版本,比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致,服务器关闭加密通信。

    Version: TLS 1.2 (0x0303)

    (2) 一个服务器生成的随机数,稍后用于生成"对话密钥"。

    GMT Unix Time: Jan 11, 2050 11:55:48.000000000 China Standard Time
    Random Bytes: 33:17:b7:9e:8d:37:b5:01:80:5c:f4:fc:3d:9f:de:1b:5d:86:11:cc:27:5e:ee:69:57:72:b3:97

    (3) 确认使用的加密方法,比如RSA公钥加密。

    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

    (4) 服务器证书。

    Compression Method: null (0)

    第三步 Server Certificate

    服务端将证书发送给客户端

    有2个证书,分别来自Blizzard Entertainment, Inc.和DigiCert Inc

    Certificate: 308205543082043ca00302010202100ebfca8ebf6dfa37ea... (id-at-commonName=*.battle.net,id-at-organizationName=Blizzard Entertainment, Inc.,id-at-localityName=Irvine,id-at-stateOrProvinceName=California,id-at-countryName=US)

    Certificate: 308204b130820399a003020102021004e1e7a4dc5cf2f36d... (id-at-commonName=DigiCert SHA2 High Assurance Server CA,id-at-organizationalUnitName=www.digicert.com,id-at-organizationName=DigiCert Inc,id-at-countryName=US)

    第四步 ServerKeyExchange

    What's the purpose of Server Key Exchange when using Ephemeral Diffie-Hellman?

    Diffie-Hellman(迪菲-赫尔曼)秘钥交换

    In Diffie-Hellman, the client can't compute a premaster secret on its own;

    both sides contribute to computing it, so the client needs to get a Diffie-Hellman public key from the server.

    In ephemeral Diffie-Hellman, that public key isn't in the certificate (that's what ephemeral Diffie-Hellman means).

    So the server has to send the client its ephemeral DH public key in a separate message so that the client can compute the premaster secret (remember, both parties need to know the premaster secret, because that's how they derive the master secret).

    That message is the ServerKeyExchange.

    EC Diffie-Hellman Server Params
    Curve Type: named_curve (0x03)
    Named Curve: secp256r1 (0x0017)
    Pubkey Length: 65
    Pubkey: 04:90:67:17:d1:ef:4d:3f:55:23:6b:69:f2:bf:9e:be:af:73:a3:e2:d5:3a:28:18:15:2a:5b:8f:62:d3:41:7b:0b:f9:bc:54:d9:32:60:49:01:17:43:31:ff:94:df:a0:d8:61:74:11:ba:a0:8e:54:73:a2:fb:df:1c:43:14:72:dc
    Signature Hash Algorithm: 0x0201
    Signature Hash Algorithm Hash: SHA1 (2)
    Signature Hash Algorithm Signature: RSA (1)

    第五步 Certificate Request[单向认证中没有这个]

    第六步 Server Hello Done

    4.3 客户端回应

    客户端收到服务器回应以后,首先验证服务器证书。

    如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期,就会向访问者显示一个警告,由其选择是否还要继续通信。

    如果证书没有问题,客户端就会从证书中取出服务器的公钥。

    然后,向服务器发送下面三项信息。

    (1) 一个随机数。该随机数用服务器公钥加密,防止被窃听。

    (2) 编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送。

    (3) 客户端握手结束通知,表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供服务器校验。

    第七步   Client Certificate  单向认证中也没有这个

    第八步 Client Key Exchange

    04:90:67:17:d1:ef:4d:3f:55:23:6b:69:f2:bf:9e:be:af:73:a3:e2:d5:3a:28:18:15:2a:5b:8f:62:d3:41:7b:0b:f9:bc:54:d9:32:60:49:01:17:43:31:ff:94:df:a0:d8:61:74:11:ba:a0:8e:54:73:a2:fb:df:1c:43:14:72:dc

     

    第九步  Certificate Verify[单向认证中也没有这个]

    第十步  Change Cipher Spec

     

     

    4.4 服务器的最后回应

    服务器收到客户端的第三个随机数pre-master key之后,计算生成本次会话所用的"会话密钥"。然后,向客户端最后发送下面信息。

    (1)编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送。

    (2)服务器握手结束通知,表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供客户端校验。

     第十一步   Change Cipher Spec

  • 相关阅读:
    部署NetCore项目(本文介绍用用IIS部署)
    vs中添加MySql实体集流程
    一文搞定HashMap的实现原理
    二分查找
    hashcode返回值可能为负数
    哈希碰撞与生日攻击
    并发的第二天
    java并发编程-1
    排序的第一天
    并发的第一天
  • 原文地址:https://www.cnblogs.com/chucklu/p/7894983.html
Copyright © 2011-2022 走看看