最近学习htpps，下面来总结一下，以下内容多来源于网上，出错不详了，仅仅当做自己做笔记用 。
密码（Cipher）
Java 1.2内置了一个叫做"JCE"(Java Crytography Extension)的系统。它主要负责Java内部的密钥和证书的管理。
众所周知，我们要给一段信息加密或者解密，就必须要有密钥。这就好比开门或者锁门，你得有一把钥匙。
这个密钥可以用Java带的KeyGenerator 或者 KeyPairGenerator生成。前者用于生成对称密钥，后者用于生成分对称密钥。
公钥也许分布广泛，但是私钥只有它的服务器知道。
在一个安全的非对称加密方案中，当使用公钥加密一段信息后，只有配对的私钥可以解密这一段信息。因此，即使黑客拿到了公钥加密信息，他也不能解密这一段信息。因为他没有配对的私钥。所以说，使用非对称加密传输的信息是安全的。
证书（Certificate）
生活中，假设你要买钻石然后进入了一家钻石店。你怎么能够知道钻石是真的。对于多数人来说，他们没有钻石相关的知识，是很难分辨钻石的真假的。但是，如果这家店有美国政府发布的的钻石营业执照，你就能确定这家店卖的是真的钻石。
证书在计算机世界好比上面说的营业执照，它可能有另一些密钥——另一个证书（假设是“B”）。这个密钥正是我需要的，而“B”则是证明这个证书是可信赖的凭证。
你可能会问:我怎么知道“B”是可信的。这是一个好问题。
Android在手机里内置了将近150份CA（certificate agent 代理证明机构）根证书。他们就好像美国的首席法官(like the chief justice in u.s)，在整个世界都是被认可的。
“B”内置了内另一个证书（C），因此我们会检查“C”是否是可信的。。。查询整条证书链，如果在这条证书链的末端或者根证书，正是我们在手机中内置的150份预设的证书之一，我们就确信原证书是合法的。
P.S. : 证书有很多格式。
PKCS12证书同时包含私钥和公钥。因此，PKCS12证书需要密码开启。
Https
最后，讲讲“https”部分。之所以前面介绍“密码”和“证书”两部分，是因为HTTPs包含它们。
HTTPs（HTTP over SSL）被设计用于在互联网中安全通信。
1. 何如安全通信？
怎么才能建立安全的通信呢？首先想到的是加密。我给需要传输的数据加密，然后将数据和“加密用的密钥”传给服务器，服务器就能使用这个k密钥解密传输的数据了。 
让我们想象这样一个场景：黑客拦截了这次通信，这意味着加密用的密钥和加密的数据都被盗取了。如果黑客有密钥，解密这段加密的数据就不是什么难事了。好了，你的数据泄露了。
2. 非对称加密（Asymmetric Cryptography）如何呢？
上一个方法一点也不安全，我们考虑下一个，非对称加密有怎么样呢？
这是一个很棒的想法。你使用服务器提供的公钥加密信息。因为服务器是唯一知道这个与公钥配对的私钥的，这意味着只有服务器能够解密这段加密的信息。这样，即使是黑客拦截了这段消息，它没有配对的私钥，也无法解密这段信息。因此，数据是安全的。
不足之处就是，非对称加密较对称加密来说，需要花费更长的时间来完成加解密的工作。出于用户体验的考虑，给一大串数据执行非对称加解密，并不是一个理想的方案。
3. 最终的方案
先前两个方案都失败了。有没有综合两个方案优势的方案呢？下面这个方案就是你需要的。
HTTPS :
上图很清楚的展示了HTTPS的执行加解密的过程
结论
因为对称加密比非对称加密快，因此HTTPS使用对称加密给数据加密，使用非对称加密加密对称加密生成的密钥，从而确保数据传输的安全性。使用这种方法，加密就变的即快速又安全了。
总之，理解HTTPS的工作原理是非常重要。这样在现实工作生活中就可以使用这种思想保证你的数据安全。
HTPPS的故事
同理，我们也把网络活动中的其他基本元素拟人化，这样这个故事才会完美 …
LiLei 跟 HanMeimei 通信，情敌 Jim Green 是个 hacker, 当然，信使自然就是 Polly 了。
接下来，请开始你的表演 …
情窦初开
李雷想告诉韩梅梅：“I LOVE U”，于是李雷写好情书，绑在 Polly 的腿上，让 Polly 去韩梅梅家，韩梅梅拿到情书，呵呵一笑，哦不，娇羞一笑，OK，一次信息传递成功。
有人使坏
然而，喜欢韩梅梅的不止李雷，还有 Jim Green，他半路截取了 Polly，看到“ I LOVE U”，顿生醋意，愤而把消息改成 “F**K OFF” … 当韩梅梅收到信时，爱情的萌芽必然就被扼杀了，因为韩梅梅并不知道李雷发来的消息被半路拦截并篡改了。
加密消息
上次的事情后，李雷花了用了 1024 天向韩梅梅解释，最终让韩梅梅相信是有人在背后捣鬼，于是，他俩这次学乖了，决定把消息加密，俩人约定好，发送时把消息中的字母都向字母表后移 1 位，也就是发送 “J MPWF V”，这时就算 Jim Green 把 Polly 截了也不知道他们的消息是什么意思，只有韩梅梅知道消息解码的规则，她将每个字母对应字母表前移一位就知道原始消息是“ I LOVE U”，掩面娇羞…
插播科普
上面这种加密消息的方式就是对称加密，你知道如何加密，也知道如何解码。然后李雷跟韩梅梅用的字母表偏移的加密方法叫 Caesarcipher,凯撒加密**。现实世界中用的加密算法会更复杂，但是基本原理相同。
假如他们之前没见过
对称加密在只有发送和接收方知道加密算法和密钥的时候，是安全的。但是问题是，如果李雷和韩梅梅在通信之前都没见过，那他们就没法约定加密算法和密钥了。
旁白：那可以先通信一次把通信方式和密码发过去，然后再发消息呗？
然而，Jim Green 又不是傻，看见 Polly 第一次飞过去，拦下来，哦，原来你们要用凯撒加密，密钥是 1 … 上面说了，加密方式只有发送方和接受者知道时是安全的，现在第三个人知道了，不安全了。
他们的通信需要更安全的加密系统 …
PS：在现实中，如果使用对称加密，客户端和服务端都需要保存大量的加密算法和对应的密钥，管理成本巨大且容易泄漏。
让 Polly 抱个密码箱
李雷和韩梅梅想出来了一个复杂的通信流程：
Polly 内心旁白，MMP，你们谈个恋爱累死老子了 …
就通过这样的流程，他们安全的谈情说爱，Jim Green 无计可施 …
插播科普
上面这种加密方式是非对称加密，非对称的含义相对于对称来说，就是你即使知道怎么加密的的方式，也不知道怎么解密，对应上面的流程就是李雷锁的密码箱却没办法打开。
术语来讲的话，就是我们熟知的公钥和私钥，服务端将公钥（密码箱）发送给客户端，客户端使用公钥加密信息（锁箱子），服务端接受消息后使用私钥（仅韩梅梅知道的密码）解密。
密码箱安全吗
然而问题还没有结束 …
李雷拿到开着的密码箱，如何确定这个密码箱就是韩梅梅让 Polly 带过来的？Jim Green 能截消息，也能截密码箱然后换成自己知道知道密码的密码箱呀，这样的话，通信同样不安全（即公钥来源的安全性）。
李雷必须要知道箱子是不是韩梅梅的，于是韩梅梅想到一个办法，她在密码箱上签上自己的名字，当李雷拿到盒子的时候，就可以看签名是不是韩梅梅的从而决定是否安全。
然而，还又同样的问题，Jim Green 同样也能伪造签名呀 …
恶魔李雷：妈蛋的，这恋爱老子不谈了！
天使李雷：山无棱天地合乃敢与君绝
天使战胜了恶魔，故事继续 …
公信的证明
我们需要一个被大家信任的人来给他们的密码箱签名从而确保身份的安全，Jesus 保佑你：
自己编的故事，哭着也要把它圆下去：
耶稣就是 Certification Authority，认证机构，被世人所信仰；
服务器把自己的公钥登录到 CA，CA 会用自己的私钥（秘术）给服务器的公钥加密生成签名（个性说明）并颁发证书（保护膜），证书中包含对公钥做的 的签名和服务端的公钥；
客户端拿到消息体后，会用浏览器内置的 CA 的公钥（圣经，人人都有）对用私钥做的签名进行验证，如果验证通过表示安全，否则表示不安全。
Polly 好累
对比最初的消息，我们为了安全，本来只用送一封信，却加了一个密码箱和一本证书，运输成本重多了，Polly 累了，不开心了 …
于是，他们决定，消息体还是以凯撒加密的方式传输，然后偏移步长用证书签名的保险箱发送，这样就可以平衡消息的安全性和传输的成本问题。
术语解释就是非对称加密会影响传输速度，因为消息体变大了，所以通常综合性能和安全性考虑，会用对称加密消息体，非对称加密用来编码对称加密的密钥。
补充
HTTPS 的相比 HTTP 的安全性提升就是因为安全通信通道的建立，也就是上文故事所描述的过程，但是还有很多对于整体通信很重要的点都没有提到。
接下来这段流程是从阮一峰 图解 SSL / TSL 协议中看到的，对与理解建立 HTTPS 的 Security 的连接会有更好理解。
客户端和服务端建立安全连接的握手过程：
结语
故事中通信的过程其实就是原始的 HTTP 到 HTTPS 的演进过程，当然隐藏了真实通信的很多细节，但是大体上描述了原理和部分细节。
去探索更多关于 HTTPS 的原理 & 申请证书改造你的网站吧 …
本篇将讨论HTTPS的加解密原理，很多人都知道RSA，以为HTTPS = RSA，使用RSA加解密数据，实际上这是不对的。HTTPS是使用RSA进行身份验证和交换密钥，然后再使用交换的密钥进行加解密数据。身份验证是使用RSA的非对称加密，而数据传输是双方使用相同的密钥进行的对称加密。那么，什么是对称加密和非对称加密？
1. 对称加密和非对称加密
假设隔壁小王想要约小红出来，但是他不想让小明知道，于是他想用对称加密给小红传了个小纸条，如下图所示：
他想发送的数据的数据是"Meet at 5:00 PM"（5点见面，如果是中文的话可以使用UTF-8编码），加密方式是直接在ASCII表进行左移或右移，他的密钥是3，表示在ASCII表往后移3位，就会变成"Phhw#dw#8=33#SP"，这样一般人如果截获了不知道是什么意思的。但是我们可以想一下，如果既然他可以载获你的数据，自然也可以截获你的密钥，进而进行解密，如下图所示：
所以小王打算用非对称加密，非对称加密的特点是双方都有自己的公钥和私钥对，其中公钥发给对方，密钥不交换自己保管不泄漏，如下图所示：
其中小红的公钥为：
public_key = (N, e) = (3233, 17)
她把公钥发给了小明，她自己的私钥为：
private_key = (N, e) = (3233, 2753)
这里注意公钥和私钥都是两个数，N通常是一个大整数，e表示一个幂指数。现在小王想给小红发消息，于是他用小红的公钥进行加密，怎么加密呢？他要发送的第一个字母为t = “M”，“M”的ASCII编码为77，77的加密过程如下计算：
T = 77 ^ e % N = 77 ^ 17 % 3233 = 3123
把77做e次幂然后模以N，便得到了T = 3123，然后把这个数发给小红（其它字母按同样方式处理）。小红收到T之后便用她的私钥进行解密，计算如下：
t = T ^ e % N = 3123 ^ 2753 % 3233 = 77
计算方法是一样的，这样便把T还原成了t，只要公私钥配对，便可通过一些数学公式证书上面的推算是成立的。这个就是RSA的加解密原理，如果无法知道私钥便无法进行正确解密。反过来，使用私钥进行加密，公钥进行解密也是可行的。那么HTTPS是怎么利用RSA进行加解密的呢，我们从HTTPS连接建立过程说起。
2. HTTPS连接建立过程
HTTPS主要有以下作用：
正如openssl的注释所说这是防止中间人攻击的唯一方法：
我们以MDN（https://developer.mozilla.org）的网站为例，然后用wireshark抓包，观察HTTPS连接建立的过程，如下图所示：
首先是TCP三次握手，然后客户端（浏览器）发起一个HTTPS连接建立请求，客户端先发一个Client Hello的包，然后服务端响应一个Server Hello，接着再给客户端发送它的证书，然后双方经过密钥交换，最后使用交换的密钥加行加解密数据。
在Client Hello里面客户端会告知服务端自己当前的一些信息，如下图所示：
包括客户端要使用的TLS版本，支持的加密套装，要访问的域名，给服务端生成的一个随机数（Nonce）等。需要提前告知服务器想要访问的域名以便服务器发送相应的域名的证书过来，因为此时还没有发生HTTP请求。
服务端在Server Hello里面会做一些响应：
服务端选中的加密套装叫TLSECDHERSAWITHAES128GCM_SHA256，这一串的意思是：
接着服务给客户端发来了4个证书：
第一个证书的公用名（common name）就是我们当前访问的域名developer.mozilla.org，如果公用名是*.mozilla.org的话那么这个证书便能给mozilla.org的所有二级子域名使用。第二个证书是第一个证书的签发机构（CA）的证书，它是Amazon，也就是说Amazon会用它的私钥给developer.mozilla.org进行签名。依此类推，第三个证书会给第二个证书签名，第四个证书会给第三个证书签名，并且我们可以看到第四个证书是一个根（Root）证书。
一个证书里面会有什么东西呢，我们可以展开第一个证书看一下，如下图所示：
证书包含三部分内容：tbsCertificate（to be signed certificate）待签名证书内容、证书签名算法和CA给的签名。也就是说CA会用它的私钥对tbsCertificate进行签名，并放在签名部分。为什么证书要签名呢？签名是为了验证身份。
3. 身份验证
我们先来看一下tbsCertificate里面有什么内容，如下图所示：
它里面包括了证书的公钥、证书的适用公用名、证书的有效期还有它的签发者等信息。Amazon的证书也具备上述结构，我们可以把Amazon证书的公钥拷出来，如下图所示：
中间有一些填充的数字，用灰色字表示。可以看到N通常是一个很大的整数（二进制2048位），而e通常为65537.
然后我们用这个CA的公钥对mozilla.org的证书签名进行解密，方法和上面的类似：
取解密后的数字decrypted的十六进制的末64位，即为二进制256位的SHA哈希签名。接下来我们手动计算一下tbsCertificate的SHA256哈希值，方法是在wireshark里面把tbsCertificate导出一个原始二进制文件：
然后再使用openssl计算它的哈希值，如下所示：
liyinchengs-MBP:https liyincheng$ openssl dgst -sha256 ~
/tbsCertificate.binSHA256(/
Users
/liyincheng/tbsCertificate.bin)=
5e300091593a10b944051512d39114d56909dc9a504e55cfa2e2984a883a827d
我们发现手动计算的哈希值和加密后的证书里的哈希值一致！说明只有知道了Amazon私钥的人才能正确地对mozilla.org的证书签名，因为公私钥是唯一匹配的。因此我们验证了第一个证书mozilla.org确实是由第二个证书Amazon签发的，使用同样的方式，我们可以验证Amazon是由第三个签发的，第三个是由第四个根证书签发。并且第四个证书是根证书，它是内置于操作系统的（通过Mac的keychain工具可以查看）：
假如Hacker通过DNS欺骗之类的方式把你访问的域名指向了他的机器，然后他再伪造一个证书。但是由于根证书都是内置于操作系统的，所以它改不了签名的公钥，并且它没有正确的私钥，只能用自己的私钥，由于公私钥不配对，很难保证加解密后的信息一致。或者直接把浏览器拿到的证书搬到他自己的服务器？这样再给浏览器发的证书便是一模一样，但是由于他不知道证书的私钥，所以无法进行后续的操作，因此这样是没有意义的。
这个就是HTTPS能够验证身份的原理。
另外一个例子是SSH，需要手动验证签名是否正确，例如通过打电话或者发邮件等方式告知服务器的签名，与自己算的证书的签名是否一致，如果一致说明证书没有被篡改过（如证书的公钥没有被改为Hacker的公钥）：
上面展示的便是自己手动计算的值，拿这个值和之前的值进行比较是否相等便可知发过来的证书是否没被修改过。
那么，为什么不直接使用RSA的密钥对进行加密数据？因为RSA的密钥对数值太大，不太合适频繁地加解密数据，所以需要更小的密钥，另一个原因是服务端没有浏览器或者客户端的密钥，无法向浏览器发送加密的数据（不能用自己的私钥加密，因为公钥是公开的）。所以需要进行密钥交换。
4. 密钥交换
密钥交换的方式有两种RSA和ECDHE，RSA的方式比较简单，浏览器生成一把密钥，然后使用证书RSA的公钥进行加密发给服务端，服务再使用它的密钥进行解密得到密钥，这样就能够共享密钥了，它的缺点是攻击者虽然在发送的过程中无法破解，但是如果它保存了所有加密的数据，等到证书到期没有被维护之类的原因导致私钥泄露，那么它就可以使用这把私钥去解密之前传送过的所有数据。而使用ECDHE是一种更安全的密钥交换算法。如下图所示，双方通过ECDHE进行密钥交换：
ECDHE的全称是Elliptic Curve Diffie–Hellman key Exchange椭圆曲线迪非-赫尔曼密钥交换，它是对迪非-赫尔曼密钥交换算法的改进，这个算法的思想如下图所示：
为了得到共享秘钥K，甲用它的私钥计算一个数g ^ a，发送给乙，乙的私钥为b，乙便得到K = g ^ a ^ b，同时发送g ^ b给甲，甲也得到了K = g ^ b ^ a。这个应该比较好理解，而引入椭圆曲线加密能够提高破解难度。
5. 椭圆曲线加密
现在的证书的签名算法有两种，RSA和新起的EC，如下图所示，google.com便是使用的ECC证书：
我们上面讨论的便是RSA，破解RSA的难点在于无法对公钥的N进行质数分解，如果你能对证书的N拆成两个质数相乘，便可推算出证书的私钥，但是在当前的计算能力下是不可能的。而ECC的破解难点在于找到指定点的系数。
如下图所示，有一条椭圆曲线方程：
y ^ 3 = x ^ 2 + ax + b:
给定一个起点G(x, y)，现在要计算点P = 2G的坐标，其过程是在G点上做一条线与曲线相切于-2G，做-2G相对于x轴的反射便得到2G点。为了计算3G的坐标，如下图所示：
连接2G与G与曲线相郊于-3G，再做反射得到3G，同理计算4G便是连接G与3G再做反射。如果最后一个点和起点的连线垂直于x轴，说明所有的点已用完。
EC的难点在于给定起点G和点K：
K = kG
想要得到k（k足够大）是一件很困难的事情。这个k便是私钥，而K = kG便是公钥。ECC是怎么加解密数据的呢？
假设要加密的数据为m，把这个点当作x坐标得到在曲线上的一个点M，取定一个随机数r，计算点C1 = rG，C2 = M + rK，把这两个点便是加密后的数据，发给对方，对方收到后使用私钥k进行解密，过程如下：
M = C2 - rK = C2 - rkG = C2 - rkG = C2 - kC1
通过上面的计算便能还原得到M. 而不知道私钥k的人是无法解密的。更多细节可见medium的这篇文章《ECC elliptic curve encryption》。这样我们便理解了ECC的原理，那么怎么利用ECC进行密钥交换呢？
6. ECC密钥交换
原理很简单，如下图所示：
之前交换的是两个幂次方的数，现在变成交换两个曲线上的点。
而曲线方程是规定好的，例如Curve X25519使用的曲线方程为：
y^2 = x^3 +486662x^2 + x
在密钥交换里面会指定所使用的曲线方程，如下图所示：
mozilla.org所使用的曲线方程为secp256r1，这个也是比较流行的一个，它的参数比Curve X25519大很多。密钥交换也使用了证书的私钥进行签名保证交换的密钥不会被人篡改，只是这里的私钥是mozilla自已的私钥。
也就是说从连接建立到现在都是明文传输的。接下来双方发送Change Cipher Spec的包通知接下来的包都按照之前约定好的方式进行加密。至此整个安全连接建立完毕。
7. HTTPS证书的应用
那么是谁在做HTTPS加密呢？服务端通常是Nginx、Apache这些反向代理服务器做的，而具体的业务服务器不需要处理，客户端通常是浏览器等做的加解密，Chrome是使用boringSSL这个库，fork自openssl。
我们可以通过let’s encrypt可以申请免费的TLS证书，每3个月需要手动续，证书分为3种：DV、OV、EV，DV适用于个人，OV和EV需要身份审核，EV最高端。EV证书会在浏览器的地址栏显示证书的企业名称：
但是新版的Chrome似乎把这个去掉了，所以我们打开medium的控制台可以看到一个提示：
As part of an experiment, Chrome temporarily shows only the lock icon in the address bar. Your SSL certificate with Extended Validation is still valid.
另外我们可以用用openssl生成一个自签名证书，执行以下命令：
openssl req -x509 -nodes -sha256 -days
365
-newkey rsa:
2048
-keyout test.com.key -
out
test.com.crt
便会得到两个文件，test.com.crt是证书，test.com.key是证书的私钥，如下图所示：
然后把这两个文件给nginx使用便能使用https访问，如下代码所示：
server {
listen 443;
server_name test.com;
ssl on;
ssl_certificate test.com.crt;
ssl_certificate_key test.com.key;
}
可以把这个证书添加到系统证书里面，这样浏览器等便能信任，或者直接使用mkcert工具一步到位。
8. 客户端证书
还有一种证书叫客户端证书，同样需要向CA机构申请一个客户端证书，和服务端TLS证书不一样的地方是，服务端证书通常是和域名绑定的，而客户端证书可以给本地的任意可执行文件进行签名。签名验证算法和上文讨论 的TLS证书一致。为什么可执行文件需要签名呢，因为如果不签名的话，系统会拦截安装或者运行，如Mac双击一个未签名的dmg包的提示：
直接不让你运行了，而windows也有类似的提示：
而windows是会给一个警告：
而当我们运行一个已签名的exe文件将会是正常的提示，如Chrome的提示：
综上本文主要讨论了对称加密和非对称加密的原理，并介绍了如何利用RSA对证书签名的检验以验证连接服务器的身份，怎么利用ECC进行数据加密和密钥交换，介绍了下怎么生成和使用HTTPS证书，并介绍了下客户端证书。相信看完本篇会对HTTPS的加解密有一个较为全面的了解，
HTTPS中S带来的性能损失
大概大家都知道为了防劫持，网站不得不用采用https。那做了这个s之后会有哪些影响呢？且看今日内容。今日早读文章由@zhitantech翻译分享。
正文从这开始~
本文编译自David Naylor et all, The Cost of the “S” in HTTPS, CONEXT 2014
动机
随着Let’s Encrypt等服务的出现，使用HTTPS的成本已经十分低廉了。也有越来越多的网站开始使用HTTPS了，在YouTube上，史无前例的有超过50%的流量使用HTTPS。HTTPS中的S是Security的含义，而我们知道，安全总是伴随着成本的上升，HTTPS也不例外。HTTP上额外的安全性会带来那些成本上的提高呢？出于这个目的，本文研究了过去三年（即2011-2014年）间的HTTPS网络流量的变化，以及TLS(Transport Layer Security)对分别在有线网、Wi-Fi和3G连接的情况下对网络延迟、数据消耗、电池消耗的影响。我们将首先介绍本文的结论，之后分别介绍HTTPS的使用趋势、对网页加载时间的影响、对数据流量的影响、对电池生命的影响，对增值服务的影响。
结论
在三个截获自普通人家中的网络和无线网络的数据集以及自己进行的实验上，得出了以下的三个结论：
HTTPS使用趋势
(注意，由于这是一篇2014年的文章，作者提及的使用成本可能不适用。在最近几年，随着Let’s Encrypt等免费的签发机构，大大降低了HTTPS的上车成本，扩大了其使用。)
通常来说，使用HTTPS都会增加基础设施的成本（如计算成本、内存、数据开销等），更主要的则是证书的成本（有的高达1999美刀一年），因此大家会想仅在必要的时候使用HTTPS。为了测试HTTPS的使用趋势，我们监测了欧洲主要的一个ISP的25,000个居民家里的网络，在监测点使用一个实现了对HTTP和HTTPS进行分类的TStat程序。对于TLS的连接，TStat解析如下的内容：
1.SNI(Server Name Indication),即欲连接的主机名。
2.服务器证书的所附带的SCN(Subject Common Name)
上图展示了从2012年4月到2014年9月的HTTPS流量变化，HTTPS流量的增长是惊人的：在两年间就增长了超过2倍。到了2014年的9月，44.3%的网络连接都已经使用了HTTPS。
对网页加载时间的影响
我们都知道使用HTTPS协议进行通信的过程中会对数据进行加密和解密，所以不难推测对于相同内容的页面在分别使用HTTP和HTTPS时的加载时间会有所不同，因此对于这一点，作者进行了验证实验。
作者分别让测试的客户端处在用3G路由器连接的无线网络环境和通过光纤连接的有线网络中，进行两次实验。每次实验，测试机均在PhantomJS浏览器中首先使用HTTP协议来加载在Alexa网站上访问量为前500的网站20次，之后使用HTTPS协议做相同的操作。实验结果如下：
由上图可以明显看出，在3G环境下，90%的网站HTTPS的额外延迟大于500ms.在有线网络下的延迟小一点，但是仍然有40%的使用HTTPS的网站需要额外加载多于500ms.
通过分别使用HTTP协议和HTTPS协议加载相同网页的对比实验得出，相比于使用HTTP协议来说，使用HTTPS的网站加载时间明显更长。
那么是什么原因导致HTTPS的加载时间更长呢？作者通过收集每个页面的HTTP请求/响应信息（HAR）发现如下图，虽然相比于HTTP，40%的网站加载HTTPS时，建立更少的TCP连接；但是，接近一半的网站在建立TCP连接时，每一次握手却需要耗费更多的时间，这部分时间主要是由TLS引起的协商开销。因此，HTTPS的加载时间反而更长。
所以不难发现，HTTPS的开销与TLS握手的延迟带来的开销息息相关，但是此时还不能排除使用HTTPS协议的网页加载时间长短是否和网络状况的好坏有关。为了更好地了解其中的原因，作者修改了Tstat，并让Tstat从2014年4月3日由RES-ISP收集的一小时pcap踪迹数据，约有100万个TLS流量中提取（i）持续时间和（ii）每次TLS握手的字节数。作者选取了美国几个具有代表性的网站进行实验。通常我们认为，网络延迟的长短与客户端和服务器的之间的远近有关，因此作者引入外部的RTT来表示上述距离，当RTT大于100ms的时候表示服务器已经在欧洲之外了。然而在实验中发现，即使是客户端与服务器的距离很近，TLS握手的持续时间仍然很长（如下图左边），以TLS协商延迟最小的Google为例（如下图中间），大约90%的TLS握手持续时间在300ms以内，10%超过300ms。由此可以看出一个完整的TLS握手请求时间至少是RTT的2倍以上，由此不难发现TLS握手请求为服务器带来的巨大额外开销。一般来时，可能由于客户或服务器开销，或网络拥塞，或缓慢的OCSP认证，5%的请求一般都会经过一个时长是RTT的10倍的握手。
更近一步看，可以发现有4％的客户体验TLS握手持续时间最短的一个连接超过300毫秒（如下图中间）。 对于这种连接，50％（75％）具有51ms（97ms）的内部RTT（即有利位置和最终用户设备之间的RTT），较不保守的阈值（例如1秒）也是如此。这表明即使是具有良好网络连接性的客户端仍然遭受TLS握手开销的困扰。 TLS快速协商有助于减少握手延迟，但是我们发现只有30％的连接被使用。 我们推测这是一个下限，但不幸的是，根据现有数据，我们无法评估从更广泛采用TLS快速协商获得的可实现的上限。
对数据流量使用的影响
HTTPS的使用对数据流量也可能会有一定的影响，这是由于：
所以我们可以将其分为两部分讨论，分别来研究。
TLS握手包的开销
TLS握手包开销的影响，很大程度上取决于整体的数据包数量：很明显，如果整体的数据包数量越大，那相对来说，协商过程中的开销所占的比重就会越低。
上图展示了各大网站中TLS握手包所占的量。我们发现，大多数TLS的连接都处于非重度使用的状态，事实上，这些连接中有一半都是TLS握手包占总的包大小的42%以上。当然，也有一些服务是非常高效率的，他们重度使用TLS的连接，例如Amazon S3，这相对地减少了在协商阶段的消耗。也有一些服务是会在真正发送数据时选择使用“预打开”连接，这掩盖了一些对延迟的影响。因为在这种情况下，如果连接没有被真正的使用，TLS的开销就会占到总开销的100%。
不过总的来说，TLS的开销大约占到总开销的5%。
网络中的代理
HTTPS会阻止一些在网络中的内容优化措施，例如一些压缩和缓存的代理。为了衡量这种无法使用代理所带来的影响，作者分析了两种生产级别的移动环境上的HTTP代理Transp-Proxy和OptIn-Proxy，Transp-Proxy是一个服务了两千万欧洲用户的、广泛应用于欧洲大型运营商的的透明代理。OptIn-Proxy则是一个每日服务两千多用户的、同样广泛应用于欧洲国家的显式代理。
作者分别讨论了HTTPS对缓存和压缩两方面的影响。
对于缓存来说，在过去两年间，Transp-Proxy的命中率约有14.9%。对于一个单一服务300万订阅者的的Transp-Proxy实例来说，这意味着每天可以节省高达2TB的流量。实际上，这一命中率已经是下降的结果了。在2012年其命中率可以达到16.8%，到了2014年就只有13.2%了。OptIn-Proxy的结果与Transp-Proxy的结果类似。
但作者也同时提到，这一命中率的下降是多种因素造成的，亦有可能是个性化的内容快速产生，使得命中率下降，也有可能是HTTPS的广泛使用使得命中率下降。但无论如何，代理节省的流量还是十分可观的，但倘若全部切换到HTTPS，就没有办法使用代理节省流量了。（不知道3年后的今天，有没有办法代理HTTPS的流量？）
第二方面则是压缩，在将内容返回用户之前，网络代理往往会做一次无损的压缩（例如使用gzip），甚至会重新编码图像或是调整图像的大小。这个功能在网络总流量有限时是非常有用的（想一想浏览器的限流模式，是不是在流量只有30M的时候非常有用）。Transp-Proxy的日志显示其压缩比例高达28.5%。对于一些重度用户，这一压缩可能是十分关键的，每个月可能都会省下数百MB的流量。
总的来说，普通用户可能没有关注到HTTPS中缓存和压缩的消失带来的流量增多，但对于运营商来说，这就是一个比较明显的趋势了。
对电池使用时间的影响
HTTPS的使用对电池的使用时间有潜在的负面影响，这是由于：
作者将实验分成了两部分，合成的内容和真实的内容。
合成内容
作者使用了一部带电表的Galaxy S II，将亮度调至最低，每200微秒测量一次电力消耗。用这部手机通过3G及Wi-Fi下载从1KB-1MB的合成的内容。每个内容都会分别使用HTTP和HTTPS下载100次。值得注意的是，作者在Android上编译了curl，以避免无关的影响。
上图展示了在不同情况下完成一次下载的平均时间和电量的消耗情况。很明显，电池电量和下载时间是相关联的。而且，对于一些大文件，在Wi-Fi情况下的开销是比较明显的（相对于3G情况下），但造成这一点的原因尚不明确。总的来说，除去下载时间不同之外，HTTPS中的加密对电池的影响是几乎没有的。
真实内容
作者首先在自己的服务器上镜像了一个CNN的首页，并且使用Android上的Chrome来分别使用HTTP和HTTPS下载50次。结果如图：
可以看出，虽然有一定的开销，但并没有十分显著。
在第二个实验中，作者播放了5-12分钟的YouTube视频。但是由于在手机上的客户端及网站没有办法播放非HTTPS的视频，所以作者强制使用桌面版本的YouTube网站来使用HTTP。经过作者的测试，在Wi-Fi情况下，HTTP和HTTPS几乎没有差别；但在3G情况下，网络中的代理极大地影响了HTTP的结果，有两个视频使用HTTP的电池电量消耗比HTTPS的结果少了将近25%，另外两个视频也节省了10%-20%。
造成这一结果的是代理的两个行为：
1.一方面，代理限制了下载速率以减少网络拥塞（这和我们下载时选择“上网优先”是类似的），同时如果用户取消了，不再看这个视频了，这样做也可以减少对网络流量的消耗（想一想，有多少次我们点开了一个视频，然后又关掉它）。如果不使用代理的话，整个视频会在进入时迅速被下载完，之后网络设备就处于休眠状态。而使用代理的话，下载速度是较慢且稳定的，在整个视频播放过程中会即放即播，因此网络设备没有休息的机会，这会导致更多的电量消耗。
2.另一方面，代理会将JavaScript插入页面中，它会改写发送到YouTube服务器上的URL，以获取更适应移动设备的编码和视频质量。对于第二个和第四个视频，最初获取了webm格式的视频，而这两种视频格式在我们的移动设备上都不支持硬解码，因此代理将其更改为了mp4格式的视频。硬解码带来的优势抵消了部分网络设备的电量消耗。
在真实情况下的实验，控制变量的难度是相当大的。因此作者也提到，对这些数字应抱有怀疑和审慎的态度(should be taken with a grain of salt)。如果试图严谨地控制变量，我们应自行建立一个HTTPS和一个HTTP的视频站点，视频源使用同一个视频的不同格式来进行这个实验。
总的来说，这个实验还是告诉我们：
HTTPS中加密的操作对电池的消耗的影响并不显著，但代理可能会极大地影响电池的生命。
运营商应仔细地考虑其中间件的设计，社区也是时候考虑是不是要全盘切换到HTTPS了。
总结和看法
鱼和熊掌不可得兼
安全和效率往往是很难同时兼顾的两面。尽管近年来的设备和技术更新已经大大降低了使用HTTPS的成本，但HTTPS的性能消耗依然是值得我们注意的一个问题。与此同时，HTTP 2.0也开始逐渐走入视野，除去安全性的考量，它的性能表现如何也是值得我们多加关注的一个话题。
但不得不说的是，在国内的网络环境下，甚至存在一些运营商劫持的问题下，网站使用HTTPS来保护用户使用过程的安全还是十分有必要的。我们也希望可信代理可以成为互联网的一个非常重要的组成部分。