个人来看,由于HTTP的不安全性,急需一个安全的协议做补充,而HTTPS就是在HTTP协议的基础上,添加了 传输层安全性协议(TLS/SSL) ,TLS/SSL是一个协议标准,而x.509则是这个协议标准的一个 实现 .而x.509就用到了加密相关的hash算法,对称加密算法,非对称加密算法.
1.ClientHello 首先https请求是基于http的，也就是基于tcp的，所以先得建立tcp三次握手，这个就不说了，然后tcp握手后是SSL层的握手，也就是图中的ClientHello消息，client发送本地最新的TLS版本、算法组合的一个集合和其他很多辅助的信息，并且生成一个随机数A。具体的内容可以看下图：
可以看到随机数（ Random ）是一个GMT UNIX时间加上一串随机字节，算法组合（ Cipher Suite ）有26种。
2.ServerHello Server收到这些信息后比对自己的TLS版本，选择其中低的一个作为返回，并且从算法组合的集合中选出一种合适的组合小火箭节点使用免费，然后同样也生成一个随机数B，一起打包到ServerHello中传回给Client。内容如图：
这里选出了一种CipherSuite算法组合。
3.Certificatie,ServerHelloDone 服务端在选出沟通策略之后将自己的证书信息告诉Client端（ Certificate ），通知Client关于秘钥更新的信息（ ServerkeyExchange ），接下去就看你的了，并且表示该发的都发给你了，我的Hello结束了（ ServerHelloDone ）。
4. Client收到2，3步的信息后先验证证书是不是合法的，包括它的颁发机构，域名匹配，有限期限等，这个具体的过程就不探究了，只要知道这些步骤就行了。
5. 证书验证通过之后，生成随机数C1,然后用证书内容中的公钥通过服务器选择的非对称加密算法加密，得出为C2。
6. 由之前的三个随机数A、B、C1通过一个伪随机函数再生成一个D， 注意！这个是最终http真正使用的加密秘钥！！！ 。
7. 由D再次通过伪随机函数生成一个秘钥组，包含6个秘钥，假设为P1,P2,P3,P4,P5,P6。
8. ClientKeyExchange。通知Server秘钥相关的信息，发送第5步中算出的C2给Server端。
9. Client端发送ClientKeyExchange之后，计算之前所有与Server端交互消息的hash值，假设为client_hash1，用步骤7中得到的其中一个P1进行加密，结果为E。
10. Server端收到C2后用私钥结合非对称算法解密C2，得到C1。
11. 同样的Server端也根据A、B、C1由伪随机函数生成D( 最终的加密秘钥！！！ ),再由D得出秘组钥（P1-P6），因为这里涉及到的算法都是一样的，所以得出的秘钥也是一样的。
12. Server端计算之前所有和Client端交互消息的hash值，假设为server_hash2，大家可能发现了，11、12跟Client端的6、7、9过程一致，只是少了9中的P1加密过程。
13. 这个时候Client端会发送ChangeCipherSpec消息和EncryptedHandshakeMessage消息，通知Server端接下去使用选定的加密策略来通信了，并且将第9步中的E传给了Server。（这里几个步骤的顺序只是为了好理解一点而这样排列，实际两条线是独立在处理信息的，所以先后顺序不能保证）
14. 这个时候Client会再次计算之前握手消息的hash值，得出结果client_hash2。
15. Server在收到EncryptedHandshakeMessage消息带过来的E之后，利用步骤11中的P1解密E，由于加密算法和P1都是相同的，所以这里还原出了client_hash1，然后与步骤12中的server_hash2比对，如果一样说明之前的几条协商秘钥的消息都被对方正确无误的理解了。
16. Server端再次对之前的消息做hash值，得出server_hash2，用P2进行加密结果为F，然后通过ChangeCipherSpec-EncryptedHandshakeMessage消息传给Client端。
17. Client收到Server的消息后根据P2解密F还原得出server_hash2，与client_hash2比对如果一致，则认为之前的交互过程都是正确无误且被对方理解的。至此，整个握手过程就结束了，之后的http数据报就会被之前确定的加密策略和加密秘钥D进行加密传输了。
总结：其实最终我们发现整个握手过程中并没有直接传输最终的加密秘钥D，而且交换了一些算法策略和生成D的一些参数，这样相对来说会更安全一点，直接传D的话这个过程就由Client端完成了，中间如果出什么差错Server会无感知无条件的信任Client传过来的D，就有可能出现问题了，所以采用只传策略和参数，并且由双方共同参与，这样安全性和正确性就会提高很多。贴一张整个过程的抓包图:
主要是为了防止 重放攻击(回放攻击) ,重放攻击是指攻击者发送一个目的主机已接收过的包，来达到欺骗系统的目的，主要用于身份认证过程，破坏认证的正确性。
浏览器客户端访问同一个https服务器，可以不必每次都进行完整的TLS Handshake，因为完整的TLS Handshake，涉及到 认证服务器的身份 （数字证书），需要做大量的非对称加密/解密运算，此外还需要做 伪随机函数PRF ，通过“ Pre-Master Key”、“Server Nonce”、“Client Nonce ”共同推导出 session key ， 非对称加密算法RSA/DSA非常耗费CPU资源。
为了克服这个困难，服务器维护一个以 session ID 为索引的结构体，用于临时存放session key，并在 TLS handshake 阶段分享给浏览器 。
当浏览器重新连接https 服务器时，TLS handshake 阶段，出示自己的session ID， 服务器获得session ID，以此为索引，可以获得和该浏览器共同拥有的session key，使用session key可以直接对用户流量做加密/解密动作。
这样避免了大量的幂、指数计算。
当然，如果服务器没有查找到session ID，双方的TLS安全参数协商按照正常流程走。
使用 charles 抓包进行分析 Session ID 的使用情况。假设有一次请求，服务端允许使用 Session ID，那么会有下面的流程：
1.客户端向服务器发起HTTPS请求
2.Charles拦截客户端的请求，伪装成客户端向服务器进行请求
3.服务器向“客户端”（实际上是Charles）返回服务器的CA证书
4.Charles拦截服务器的响应，获取服务器证书公钥，然后自己制作一张证书，将服务器证书替换后发送给客户端。（这一步，Charles拿到了服务器证书的公钥）
5.客户端接收到“服务器”（实际上是Charles）的证书后，生成一个对称密钥，用Charles的公钥加密，发送给“服务器”（Charles）
6.Charles拦截客户端的响应，用自己的私钥解密对称密钥，然后用服务器证书公钥加密，发送给服务器。（这一步，Charles拿到了对称密钥
7.服务器用自己的私钥解密对称密钥，向“客户端”（Charles）发送响应
8.Charles拦截服务器的响应，替换成自己的证书后发送给客户端
至此，连接建立shadowx安卓版，Charles拿到了 服务器证书的公钥 和 客户端与服务器协商的对称密钥，之后就可以解密或者修改加密的报文了。
(核心点:Charles生成了自己一套公钥,私钥,和自己的证书,因为自己的证书无法通过校验,所以需要客户端主动授权,客户端授权后,charles就可以完全代替客户端与服务端交互,与服务端交互用的是服务端的公钥加密,与客户端交互用的是charles自己的私钥解密)
facebook三个好友验证码哪里找
如果说你是购买的Facebook双重验证账号的话。这个地方所显示的验证码，它并不是你的手机号码的验证码。它其实就是32位的密钥进行解密之后的验证码，类似于我们的短信验证码。你在购买Facebook账号的时候，信息资料里面会有。直接到指定的网站去进行解码就可以了。
为什么很多人会验证码出错？
非常简单，就是他的解密出现了问题，你要注意是32位。
而且很多人可能分不清楚账号信息里面的信息。
甚至有人拿邮箱直接去进行解密，又或者说是UI要地址直接拿去解密，这种错误就不要犯了。
通常情况下它就是一串数字和字母的组合。也非常容易识别，你想账号里面有没有32位的其实非常少，除此之外像什么邮箱邮箱密码之类的，都不可能有这么长的数字。32位。
特别容易识别啊。
解密之后就会有6个数字，你说是不是和我们手机收到的短信验证码是一样的，它其实就是代替我们的手机号码去接收验证码，因为Facebook在很多时候针对国内的手机，它是不能发送验证码的，又或者说经常会出错。所以我们使用的Google的身份验证器来代替我们的手机接收验证码，就是这个道理。
1、通常情况下你在登录Facebook的时候只有这一个地方，输入成功之后，你的账号就直接进入了Facebook。但是如果你在接下来的步骤当中碰到你，还需要去进行验证。
比方说印证你的邮箱。那这个很明显就是你登录的时候触发了Facebook某一个机制，他觉得你这个账号有风险，需要你去验证一下你的邮箱。请注意问题是出在你的设备和环境上面，以及你的线路IP上面。与Facebook账号是没有多大关系的。
2、facebook登录验证手机。还有一种情况就是他不需要你去验证你的邮箱了，他直接要你去验证一个Facebook手机号码，那这种你的风险级别比前面一种还要大一些。因为他觉得邮箱没有问题，但是你的风险级别太高了，你需要去绑定一个手机号码才能继续使用这个Facebook。
这个道理也非常简单，一想就想通了嘛。
3、那么安全级别比上面这几个更高的，也就是说你的风险大到非常大的时候，他就会要求你直接去验证你的身份证。facebook登录验证身份对于新购买的Facebook账号基本上是不会通过的。所以到了这个地方你就直接pass。
不用去浪费你的时间和精力了。
把你所有的时间和精力，又在怎么样去解决你的电脑和手机设备以及线路IP的问题。因为他们肯定是有问题的，风险级别过大，甚至会造成你在中途去验证你的邮箱的时候，你会发现，登录你的邮箱居然还是需要去验证或者去绑定一些手机号，你就可想而知连一个邮箱都能够检测出来你的环境风险很大，何况是Facebook的。
所以你也需要把这些所有的不同的风险级别，不同的安全要求通通去梳理一遍，这样的话你登录Facebook是没有任何问题的。
而且我们在猎刀手的文章当中有详细的说道。
一劳永逸的解决办法，又或者说是直接抛开所有这些问题，最简单直白的解决办法就是直接去购买一个腾讯云阿里云或者亚马逊云的远程，VPS服务器你直接在上面登录。那么你几乎都可以排除前面所有的问题了。
还没有评论，来说两句吧...