https ssl 原理

https中s是ssl

http端口是80端口

https是443端口

80端口是来传输数据的

443端口是来解决以什么样方式建立连接

http://baidu.com   80端口

 

 上面就是http协议，中间要进过许多节点，最终到达请求的服务器，

由于http协议是明文传输数据，所以这些节点都能拦截数据，不安全

相当于裸奔。

所以需要一种加密算法，加密对应解密  encode(原话)  decode(密文)=原话

摘要算法：防止篡改，是不可以解密的，sha1,sha2,sha256,sha512,这些算法加密后就是摘要

而签名是对某一内容有有一个认证机制，如对以文件进行摘要算法得到hash值，然后连同原文，摘要算法以发送给另一方，另一方只要通过摘要算法对原文加密，然后与闯过来的摘要比对，就可以保证这份文件没有被篡改，但是对原文进行签名，然后交给另一方，这签名可能是假的，签名是保证签名是真实的。

要保证传输的加密算法是安全的，不被拦截

 

 所以要对加密算法+盐（秘钥），加密算法可以被中间人获取到，只要保证盐不被获取即可，这个秘钥不能用明文传输

所以引入非对称加密，秘钥混合加密算法，生成密文，这个秘钥不能通过网络传，因为这个是私有东西，就像房门的钥匙，谁获取谁就能开启大门，秘钥生成新的秘钥（公钥），然后将新的秘钥给对方。

例子：单点登录，免密登录，就是用当前私钥生成公钥出来，然后拷贝到另一台电脑上，github下载一个公钥，私钥永远在服务器端，在https中没办法将公钥内置到协议中

私钥对数据加密得到密文，然后对密文用公钥还原原文。也不安全.中间人也可以获取公钥，然后仍然可以解密密文，拦截了，所以公钥不能通过网络传输。所以要改成公钥加密，私钥解密。

公钥加密的东西，公钥解不开，私钥加密私钥可解，公钥可解。公钥加密不能篡改只能看，服务器端通过网络将公钥给中间人和浏览器，中间人可以看，但中间人如果用公钥加密，浏览器用公钥解不开

其中一种：凯撒加密算法  .rar 压缩  ，解压缩 同一套算法

浏览器和服务器端 协商加密算法，浏览器和服务器一方发送加密算法给另一方，另一方可能会不支持所给的加密算法，那就是白

给了，443端口作用来了：

1、浏览器提交支持的算法列表    hi,在吗？

2、服务器收到请求后，和当前服务器端支持的加密算法比对一下，下发一个优先级高的加密算法给客户端   hello 在

共4次握手，前面两次握手就是上面两步

 

问题来了：发送加密算法的时候有什么安全问题？

模拟一个中间服务器，代码可以获取443发送的数据，也可以获取80端口获取的数据，所以发送的加密算法也是可以被中间人获取到

 

 

 

---

 

https://baidu.com 默认往443

1.443端口发请求

2.

3接着向80端口发送数据

知名端口即众所周知的端口号，范围从0到1023，这些端口号一般固定分配给一些服务。比如21端口分配给FTP服务，25端口分配给SMTP（简单邮件传输协议）服务，80端口分配给HTTP服务，135端口分配给RPC（远程过程调用）服务

https是服务端由一个服务注册443端口，比如iis， nginx，apache等都可以注册443端口，这些服务器配置文件中有默认443