有哪些加密网站，如https开头的网址？

https代表该网站是经过加密的，可信任网站！ HTTPS（Secure Hypertext Transfer Protocol）安全超文本传输协议 HTTPS协议是由Netscape开发并内置于其浏览器中，用于对数据进行压缩和解压操作，并返回网络上传送回的结果。HTTPS实际上应用了Netscape的完全套接字层（SSL）作为HTTP应用层的子层。（HTTPS使用端口443，而不是象HTTP那样使用端口80来和TCP/IP进行通信。）SSL使用40 位关键字作为RC4流加密算法，这对于商业信息的加密是合适的。HTTPS和SSL支持使用X.509数字认证，如果需要的话用户可以确认发送者是谁。 Https是保密性的超文本传送协议 就是使用ssl加密后的超文本传送协议. 浏览器都可以支持这种协议下的网络文档,前提是你具备对方提供的安全证书. 我在IBM的主页搜到的是如下说明： 引用内容： 使用HTTPS 协议 对于安全通信，请使用安全协议 HTTPS 来代替 HTTP。 对于Web 浏览器和 Tivoli License Manager 服务器间的通信，这通过在寻址以下服务器界面的登录页时使用 HTTPS 来完成： 管理服务器 https://<server name>: ... slmadmin/login 运行时服务器 https://<server name>:&... mruntime/login 对于与管理服务器的通信，运行时服务器使用以下格式的 scp.properties 文件中的 adminpath 属性中的值： adminpath = http://<server name>:<port>/slmadmin/service 它是用于与管理服务器通信的地址和端口。如果安装的服务器启用了 SSL，则该地址启动 https，且端口为安全端口 443。如果在安装时没有启用 SSL 且决定在以后启用它，则您必须编辑 scp.properties 文件，并更改 adminpath 属性以使用 https 和端口443。scp.properties 文件存储在运行时服务器计算机上的以下位置中： <INSTALL_DIR>\runtime\conf 运行时和管理服务器间的安全通信需要密码以访问每个运行时服务器上的 key.jks 数据库。当安装运行时服务器的 SSL 选项时，安装向导将请求 SSL 密码。如果安装服务器时关闭了 SSL 且决定以后再启用它，则您必须从 Tivoli License Manager 命令行使用 sslpasswd 命令来设置 SSL 密码。请参阅sslpasswd。

https作用：

1.保护隐私：所有信息都是加密传播，第三方无法窃听数据。如果使用HTTP明文传输数据的话，很可能被第三方劫持数据，那么所输入的密码或者其他个人资料都被暴露在他人面前，后果可想而知。

2.数据完整性：一旦第三方篡改了数据，接收方会知道数据经过了篡改，这样便保证了数据在传输过程中不被篡改 —— 数据的完整性。

3.身份认证：第三方不可能冒充身份参与通信，因为服务器配备了由证书颁发机构（Certificate

Authority，简称CA）颁发的安全证书，可以证实服务器的身份信息，防止第三方冒充身份。（也有少数情况下，通信需要客户端提供证书，例如银行系统，需要用户在登录的时候，插入银行提供给用户的USB，就是需要客户端提供证书，用来验证客户的身份信息。）

https原理：

http+ssl证书=https

像目前JoySSL品牌的ssl证书很优质，有着多种品牌证书，价格方面性价比也很高。JoySSL：https安全证书

很多人说“不用HTTPS就是裸奔”

HTTP的不足：

通信使用明文（不加密），内容可能会被窃听(wireshark/fiddler)

不验证通信方的身份，因此有可能遭遇伪装

无法证明报文的完整性，所以有可能已遭篡改

TCP/IP 是可能被窃听的网络

1.通讯的加密：

SSL(Secure Socket Layer,安全套接层）或TLS(Transport Layer Security,安全层传输协议)

有兴趣深入SSL/TLS: https://www.jianshu.com/p/3e5f01360827

用 SSL 建立安全通信线路之后，就可以在这条线路上进行 HTTP通信了。与 SSL 组合使用的 HTTP 被称为 HTTPS（HTTP Secure，超文本传输安全协议）或 HTTP over SSL。

2.内容的加密：

为了做到有效的内容加密，前提是要求客户端和服务器同时具备加密和解密机制。主要应用在 Web 服务中。有一点必须引起注意，由于该方式不同于 SSL 或 TLS 将整个通信线路加密处理，所以内容仍有被篡改的风险。

不验证通讯方的身份就可能遭遇伪装

无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器。

无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。

无法确定正在通信的对方是否具备访问权限。因为某些Web 服务器上保存着重要的信息，只想发给特定用户通信的权限。

无法判定请求是来自何方、出自谁手。

无法证明报文的完整性，可能已遭篡改

如何防篡改？

可以使用MD5和SHA-1等散列算法，但这仍然无法百分百保证结果的正确，因为散列码如果同时被修改的话，用户还是无法意识到文件已经被修改。还是用HTTPS吧。

HTTP+ 加密 + 认证 + 完整性保护=HTTPS

HTTP是身披SSL外壳的HTTP

相互交换密钥的公开密钥加密技术 ：

共享密钥加密的问题：

证明公开密钥的正确性的证书：

也可以通过设置->高级->管理HTTPS证书来查看所有已经安装的证书（chrome浏览器）

HTTPS的安全通信机制：

步骤 1： 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。

步骤 2： 服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。

步骤 3： 之后服务器发送 Certificate 报文。报文中包含公开密钥证书。

步骤 4： 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。

步骤 5： SSL 第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-mastersecret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。

步骤 6： 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。

步骤 7： 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。

步骤 8： 服务器同样发送 Change Cipher Spec 报文。

步骤 9： 服务器同样发送 Finished 报文。

步骤 10： 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用层协议的通信，即发送 HTTP 请求。

步骤 11： 应用层协议通信，即发送 HTTP 响应。

步骤 12： 最后由客户端断开连接。断开连接时，发送 close_notify 报文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP的通信。

问题：为何不完全使用非对称加密算法，而是使用非对称加密算法传送密钥，对称加密算法加密内容？（性能问题）

常见对称加密算法:AES/DES

常见非对称加密算法：RSA

对称加密算法和非对称加密算法速度对比：

https://blog.csdn.net/wowotuo/article/details/80295586

要进行 HTTPS 通信，证书是必不可少的。而使用的证书必须向认证机构（CA）购买。证书价格可能会根据不同的认证机构略有不同。通常，一年的授权需要数万日元（现在一万日元大约折合 600人民币）。

https不是只有信徒，google的霸道也引来了很多的反抗者~

1.chrome浏览器将非https站点默认标注为“不安全”的

2.SEO，不https就掐掉流量。。。

RSS 之父 Winer 炮轰 Google 反客为主强推 HTTPS：

https://www.oschina.net/news/97660/dave-winer-criticize-google

搭建一个https服务端：

https://www.jianshu.com/p/c59ea7d0230e

windows server上的一个简单https例子(不想乱搞测试环境，就没弄Linux)：

---