全网HTTPS加密

HTTPS 到底加密了什么?

2018/07/03 · 基础技术 ·
HTTPS

原文出处:
云叔_又拍云   

关于 HTTP 和 HTTPS
这个老生常谈的话题,我们之前已经写过很多文章了,比如这篇《从HTTP到HTTPS再到HSTS》,详细讲解了
HTTP 和 HTTPS 的进化之路,对的没错,就是 HTTP 兽进化 HTTPS 兽。

图片 1

那么今天我们主要聊一聊 HTTPS 到底加密了些什么内容。

先跟大家讲个故事,我初恋是在初中时谈的,我的后桌。那个时候没有手机这类的沟通工具,上课交流有三宝,脚踢屁股、笔戳后背以及传纸条,当然我只能是那个屁股和后背。

说实话传纸条真的很危险,尤其是这种早恋的纸条,被抓到就是一首《凉凉》。

于是我和我的小女朋友就商量一下加密这个小纸条上面的数据,这样就算被班主任抓到她也奈何不了我们!

我们用将英文字母和数字一一对应,组成一个密码本,然后在小纸条上写上数字,要将他翻译成对应的字母,在拼成拼音才能知道这串数字意思。

上面就是最初我坎坷的感情史。

后来等我长大了,才知道这是回不去的美好。如果给我一个机会,我愿意……啊呸,跑偏了,等长大了才知道,这个就是现在网站数据传输中的
HTTPS。

最近看了一些协议,下面就用一些例子来说明HTTPS中SSL/TLS协议.

最近有不少网站被劫持,导致网站流量大量流失,这时候可能就要考虑是不是域名被劫持了,网站假如没有安装SSL证书,那很有可能是域名被黑客劫持了,安装SSL证书,去环洋诚信申请,合理的价格,一流的服务,随时为您网站保驾护航。

学习文章

  • iOS9AdaptationTips
  • 打造安全的App!iOS安全系列之 HTTPS

多了 SSL 层的 HTTP 协议

简而言之,HTTPS 就是在 HTTP 下加入了 SSL
层,从而保护了交换数据隐私和完整性,提供对网站服务器身份认证的功能,简单来说它就是安全版的
HTTP。

现在随着技术的发展,TLS 得到了广泛的应用,关于 SSL 与 TLS
的差别,我们不用在意,只要知道 TLS 是 SSL 的升级版本就好。
图片 2
一般来说,HTTPS
主要用途有三个:一是通过证书等信息确认网站的真实性;二是建立加密的信息通道;三是数据内容的完整性。
图片 3

上文为又拍云官网,我们可以通过点击浏览器地址栏锁标志来查看网站认证之后的真实信息,SSL证书保证了网站的唯一性与真实性。

那么加密的信息通道又加密了哪些信息呢?

签发证书的 CA
中心会发布一种权威性的电子文档——数字证书,它可以通过加密技术(对称加密与非对称加密)对我们在网上传输的信息进行加密,比如我在
Pornhub 上输入:

账号:cbssfaw

密码:123djaosid

可是这个数据被黑客拦截盗窃了,那么加密后,黑客得到的数据可能就是这样的:

账号:çµø…≤¥ƒ∂ø†®∂˙∆¬

密码:∆ø¥§®†ƒ©®†©˚¬

图片 4

最后一个就是验证数据的完整性,当数据包经过无数次路由器转发后会发生数据劫持,黑客将数据劫持后进行篡改,比如植入羞羞的小广告。开启HTTPS后黑客就无法对数据进行篡改,就算真的被篡改了,我们也可以检测出问题。

鲍勃和他们的朋友在不同的地方,他们通过网络联系.

概念释疑

为了强制增强数据访问安全,iOS9 默认会把所有从 NSURLConnection
CFURLNSURLSession发出的 HTTP请求,都改为 HTTPS
请求:iOS9.x-SDK编译时,默认会让所有从NSURLConnectionCFURL
NSURLSession发出的 HTTP 请求统一采用TLS 1.2 协议。因为
AFNetworking 现在的版本底层使用了 NSURLConnection
,众多App将被影响(基于iOS8.x-SDK的App不受影响)。服务器因此需要更新,以解析相关数据。而这一做法,官方文档称为ATS,全称为App Transport Security,是iOS9的一个新特性。如不更新,可通过在
Info.plist 中声明,倒退回不安全的网络请求。一个符合 ATS 要求的
HTTPS,应该满足如下条件:

  • Transport Layer Security协议版本要求TLS1.2以上
  • 服务的Ciphers配置要求支持Forward Secrecy等
  • 证书签名算法符合ATS要求等

注: ATS只信任知名CA颁发的证书,小公司所使用的 self signed
certificate,还是会被ATS拦截。

HTTPS那些事(一)HTTPS原理

对称加密与非对称加密

对称加密

对称加密是指加密与解密的使用同一个密钥的加密算法。小编初中的时候传纸条使用了同一套加密密码,所以我用的加密算法就是对称加密算法。

目前常见的加密算法有:DES、AES、IDEA 等

非对称加密

非对称加密使用的是两个密钥,公钥与私钥,我们会使用公钥对网站账号密码等数据进行加密,再用私钥对数据进行解密。这个公钥会发给查看网站的所有人,而私钥是只有网站服务器自己拥有的。

目前常见非对称加密算法:RSA,DSA,DH等。

但是他们发现这样的方式不安全,因为消息在传输过程中可能被偷窥,甚至被修改.

什么是SSL/TLS?跟HTTP和HTTPS有什么关系?

什么是SSL/TLS?
SSL你一定知道,在此不做赘述。主要说下什么是TLS,还有跟HTTP和HTTPS有什么关系。TLS
是 SSL
新的别称:“TLS1.0”之于“SSL3.1”,犹“公元2015”之于“民国104”,“一千克”之于“一公斤”:称呼不同,意思相同。SSL
3.0版本之后的迭代版本被重新命名为TLS 1.0:TLS 1.0=SSL
3.1。所以我们平常也经常见到 “SSL/TLS” 这种说法。目前,应用最广泛的是TLS
1.0,接下来是SSL 3.0。目前主流浏览器都已经实现了TLS
1.2的支持。常用的有下面这些:

  • SSL 2.0
  • SSL 3.0
  • TLS 1.0
  • TLS 1.1
  • TLS 1.2 那为什么标题是“使用HTTPS”而没有提及SSL和TLS什么事?
    “SSL/TLS”跟HTTP和HTTPS有什么关系?要理解这个,要看下他们之间的关系:HTTP+SSL/TLS+TCP = HTTPS

图片 5HTTPS.jpg或者HTTPS = “HTTP over SSL”

也就是说

Apple让你的HTTP采用SSL/TLS协议,就是让你从HTTP转到HTTPS。而这一做法,官方文档称为ATS,全称为App Transport Security。

HTTPS=数据加密+网站认证+完整性验证+HTTP

通过上文,我们已经知道,HTTPS 就是在 HTTP
传输协议的基础上对网站进行认证,给予它独一无二的身份证明,再对网站数据进行加密,并对传输的数据进行完整性验证。

HTTPS 作为一种加密手段不仅加密了数据,还给了网站一张身份证。

如果让我回到十年前,那么我一定会这样跟我的女朋友传纸条:

先准备一张独一无二的纸条,并在上面签上我的大名,然后用只有我女朋友可以解密的方式进行数据加密,最后写完后,用胶水封起来,防止隔壁桌的小王偷看修改小纸条内容。

 

1 赞 收藏
评论

图片 6

于是他们想了个办法,鲍勃使用通过秘钥把明文加密,写在信件中,�收件人在收到消息的时候,通过秘钥解密把密文成明文.就算消息被拦截,也无法解密消息.

为什么要用SSL/TLS?

不使用SSL/TLS的HTTP通信,就是不加密的通信!

不使用SSL/TLS的HTTP通信,所有信息明文传播,带来了三大风险:

  • 窃听风险(eavesdropping):第三方可以获知通信内容。
  • 篡改风险(tampering):第三方可以修改通信内容。
  • 冒充风险(pretending):第三方可以冒充他人身份参与通信。

SSL/TLS协议是为了解决这三大风险而设计的,希望达到:

  • 所有信息都是加密传播,第三方无法窃听。
  • 具有校验机制,一旦被篡改,通信双方会立刻发现。
  • 配备身份证书,防止身份被冒充。

SSL/TLS的作用,打个比方来讲:

如果原来的 HTTP 是塑料水管,容易被戳破;那么如今新设计的 HTTPS
就像是在原有的塑料水管之外,再包一层金属水管(SSL/TLS协议)。一来,原有的塑料水管照样运行;二来,用金属加固了之后,不容易被戳破。

谣言粉碎机前些日子发布的《用公共WiFi上网会危害银行账户安全吗?》,文中介绍了在使用HTTPS进行网络加密传输的一些情况,从回复来看,争议还是有的。随着网络越来越普及,应用越来越广泛,一些网络安全问题也会越来越引起网民的关注,在这里和大家一起聊聊TLS/SSL也就是我们常说的HTTPS,从原理到实际应用看清它到底是怎么一回事,以及在使用HTTPS要注意哪些问题以及相关的安全技巧。

他们在通信中使用同一个秘钥用来加密和解密,也就是对称性加密.

解决方案

网络安全是一个整体的事件,涉及到个人计算机的安全,协议的安全,传输数据的安全,以及软件开发公司和网站的安全,单纯的依靠一个HTTPS协议并不能解决所有的问题。希望通过今后一点一点的对安全相关的问题进行说明解释,能让更多人对网络安全有所了解,从而更安全的使用网络。

有人可能要问了,他们秘钥都是同一个,那么他们怎么把秘钥传递给对方呢,如果直接放在消息里,万一被人拦截了,那加密不就白费了?

符合ATS

如果所有请求接口都符合ATS,那么,对于前端来说,则不需要做任何额外工作.

文章会比较长,暂时计划分成三个部分:

于是他们想了个绝妙的办法来解决这个问题——非对称性加密.

不完全符合ATS

这是很有可能的,因为即使公司的正式接口符合ATS,开发中,还是需要测试接口的.我们很有可能没有时间金钱,使测试接口也符合ATS,也没必要.

对于不完全符合ATS的情况,我们可以通过调整plist来轻松做到.

图片 7Exception.png

正如在上图中看到的,苹果官方提供了一些可选配置项来决定是否开启ATS模式.

开发者可以针对某些确定的URL不使用ATS,这需要在工程中的info.plist中标记NSExceptionDomains。在NSExceptionDomains字典中,可以显式的指定一些不使用ATS的URL.键值如下:

  • NSIncludesSubdomains
  • NSExceptionAllowInsecureHTTPLoads
  • NSExceptionRequiresForwardSecrecy
  • NSExceptionMinimumTLSVersion
  • NSThirdPartyExceptionAllowsInsecureHTTPLoads
  • NSThirdPartyExceptionMinimumTLSVersion
  • NSThirdPartyExceptionRequiresForwardSecrecy

关于App Transport
Security,每个应用都属于4个大类当中的一类。我们来看看每一个大类都是怎样影响应用的。

分类名 解释
1. HTTPS Only (只有HTTPS,所有情况下都使用ATS) 如果你的应用只基于支持HTTPS的服务器,那么你太幸运了。你的应用不需要做任何改变。但是,注意App Transport Security要求TLS 1.2而且它要求站点使用支持forward secrecy协议的密码。证书也要求是符合ATS规格的。因此慎重检查与你的应用交互的服务器是不是符合ATS的要求非常重要。
2. Mix & Match 你的应用与一个不符合ATS要求的服务器工作是很有可能的。在这种情况下,你需要告诉操作系统哪些站点是涉及到的然后在你的应用的 Info.plist文件中指明哪些要求没有达到。
3. Opt Out 如果你在创建一个网页浏览器,那么你有一个更大的麻烦。因为你不可能知道你的用户将要访问那个网页,你不可能指明这些网页是否支持ATS要求且在HTTPS上传输。在这种情况下,除了全部撤销 App Transport Security 没有其它办法。
4. Opt Out With Exceptions(除特殊情况外,都不使用ATS) 当你的应用撤消了App Transport Security,,但同时定义了一些例外。这非常有用就是当你的应用从很多的服务器上取数据,但是也要与一个你可控的API交互。在这种情况下,在应用的Info.plist文件中指定任何加载都是被允许的,但是你也指定了一个或多个例外来表明哪些是必须要求 App Transport Security的。

根据上表,分别做一下解释

1.HTTPS Only (只有HTTPS,所有情况下都使用ATS

如果你的应用只基于支持HTTPS的服务器,那么你太幸运了。你的应用不需要做任何改变。

2.Mix & Match

你的应用与一个不符合ATS要求的服务器工作是很有可能的.

我们拿三个域名来举例子:

1.api.insecuredomain.com

我们要让这个域名的请求使用http

Info.plist 配置中的XML源码如下所示:

 <key>NSAppTransportSecurity</key> <dict> <key>NSExceptionDomains</key> <dict> <key>api.insecuredomain.com</key> <dict> <!--允许App进行不安全的HTTP请求--> <key>NSExceptionAllowsInsecureHTTPLoads</key> <true/> <!--适用于这个特定域名下的所有子域--> <key>NSIncludesSubdomains</key> <true/> </dict> </dict> </dict> 

在 plist 文件里显示如下:

图片 8NSExceptionAllowsInsecureHTTPLoads.png

我们定义的第一个“例外”(Exception)告诉ATS当与这个子域交互的时候撤销了必须使用HTTPS的要求。注意这个仅仅针对在“例外”(Exception)中声明了的子域。非常重要的一点是要理解NSExceptionAllowsInsecureHTTPLoads关键字并不仅仅只是与使用HTTPS相关。这个“例外”(Exception)指明了对于那个域名,所有的App
Transport Security的要求都被撤销了。

2.cdn.domain.com

我们要让这个域名使用低于TLS1.2的加密协议

Info.plist 配置中的XML源码如下所示:

 <key>NSAppTransportSecurity</key> <dict> <key>NSExceptionDomains</key> <dict> <key>cdn.somedomain.com</key> <dict> <key>NSThirdPartyExceptionMinimumTLSVersion</key> <string>TLSv1.1</string> </dict> </dict> </dict> 

在 plist 文件里显示如下:

图片 9NSThirdPartyExceptionMinimumTLSVersion.png

很可能你的应用是与一个支持HTTPS传输数据的服务器交互,但是并没有使用TLS
1.2或更高(上例中为TLS1.1)。在这种情况下,你定义一个“例外”(Exception),它指明应该使用的最小的TLS的版本。这比完全撤销那个域名的App
Transport Security要更好更安全。

3.thatotherdomain.com

我们要让这个域名不支持ForwardSecrecy,同时,综合一下上面的用法

Info.plist 配置中的XML源码如下所示:

 <key>NSAppTransportSecurity</key> <dict> <key>NSExceptionDomains</key> <dict> <key>thatotherdomain.com</key> <dict> <!--适用于这个特定域名下的所有子域--> <key>NSIncludesSubdomains</key> <true/> <!--扩展可接受的密码列表:这个域名可以使用不支持 forward secrecy 协议的密码--> <key>NSExceptionRequiresForwardSecrecy</key> <false/> <!--允许App进行不安全的HTTP请求--> <key>NSExceptionAllowsInsecureHTTPLoads</key> <true/> <!--在这里声明所支持的 TLS 最低版本--> <key>NSExceptionMinimumTLSVersion</key> <string>TLSv1.1</string> </dict> </dict> </dict> 

在 plist 文件里显示如下:

图片 10NSExceptionRequiresForwardSecrecy.png

NSIncludesSubdomains 关键字告诉 App Transport Security
这个“例外”(Exception)适用于这个特定域名的所有子域。这个“例外”(Exception)还进一步通过扩展可接受的密码列表来定义这个域名可以使用不支持forward
secrecy( NSExceptionRequiresForwardSecrecy ) 协议的密码.

如果你的App中同时用到了这三个域名,那么应该是这样:

 <key>NSAppTransportSecurity</key> <dict> <key>NSExceptionDomains</key> <dict> <key>api.insecuredomain.com</key> <dict> <key>NSExceptionAllowsInsecureHTTPLoads</key> <false/> </dict> <key>cdn.somedomain.com</key> <dict> <key>NSThirdPartyExceptionMinimumTLSVersion</key> <string>TLSv1.1</string> </dict> <key>thatotherdomain.com</key> <dict> <key>NSIncludesSubdomains</key> <true/> <key>NSExceptionRequiresForwardSecrecy</key> <false/> </dict> </dict> </dict> 

在 plist 文件里显示如下:

图片 11综合.png

3. Opt Out

上面是比较严谨的做法,指定了能访问哪些特定的HTTP。当然也有暴力的做法:
彻底倒退回不安全的HTTP网络请求,能任意进行HTTP请求,比如你在开发一款浏览器App,或者你想偷懒,或者后台想偷懒,或者公司不给你升级服务器…

你可以在Info.plist 配置中改用下面的XML源码:

 <key>NSAppTransportSecurity</key> <dict> <!--彻底倒退回不安全的HTTP网络请求,能任意进行HTTP请求 --> <key>NSAllowsArbitraryLoads</key> <true/> </dict> 

在 plist 文件里显示如下:

图片 12禁用ATS.png

4. Opt Out With Exceptions(除特殊情况外,都不使用ATS)

上面已经介绍了三种情景,还有一种可能你也会遇到:

当你的应用撤消了App Transport
Security,,但同时定义了一些“例外”(Exception)。当你的应用从很多的服务器上取数据,但是也要与一个你可控的API交互。在这种情况下,在应用的Info.plist文件中指定任何加载都是被允许的,但是你也指定了一个或多个“例外”(Exception)来表明哪些是必须要求
App Transport Security的。下面是Info.plist文件应该会有的内容:

<key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <true/> <key>NSExceptionDomains</key> <dict> <key>api.tutsplus.com</key> <dict> <key>NSExceptionAllowsInsecureHTTPLoads</key> <false/> </dict> </dict> </dict> 

在 plist 文件里显示如下:

图片 13除特殊情况外,都不使用ATS.png

第一部分主要描述HTTPS的原理;第二部分主要描述SSL证书验证的过程与使用的一些注意事项;第三部分会呈现一些针对HTTPS攻击的实例。如果有需要,我会后续的补充一些内容。

什么是非对称性加密呢

Certificate Transparency

虽然ATS大多数安全特性都是默认可用的,Certificate Transparency
是必须设置的。如果你有支持Certificate
Transparency的证书,你可以检查NSRequiresCertificateTransparency关键字来使用Certificate
Transparency。再次强调,如果你的证书不支持Certificate
Transparency,此项需要设置为不可用。

如果需要调试一些由于采用了ATS而产生的问题,需要设置CFNETWORK_DIAGNOSTICS为1,这样就会打印出包含被访问的URL和ATS错误在内的NSURLSession错误信息。要确保处理了遇到的所有的错误消息,这样才能使ATS易于提高可靠性和扩展性。

我尽量使用最简洁的语言来描述相关的概念,这里开始先挖个坑,然后慢慢地填。

  1. 非对称性加密拥有两个秘钥——私钥公钥.
    私钥是私有的,公钥则是可以公开.
  2. 私钥加密只能公钥解.
  3. 公钥加密只能私钥解.

说明

  1. 在使用Xcode7,并且Base SDK用的iOS9及以上版本,才需要网络适配ATS。
  2. 在OS X EI
    Capitan系统的终端中通过nscurl命令来诊断检查你的HTTPS服务配置是否满足Apple的ATS要求:

 $ nscurl --verbose --ats-diagnostics https://<your_server_domain> 

HTTPS那些事(二)SSL证书

当鲍勃想和他的朋友通信时候,比如爱丽丝.他首先发个消息给爱丽丝,请求爱丽丝给他公钥,当爱丽丝给他公钥的时候,鲍勃就用公钥加密,发送给爱丽丝.而爱丽丝就用她得私钥解密消息,并且用私钥加密回复内容,发送给鲍勃,鲍勃又用公钥解密.

Demo

我们写一个Demo来说明会更清晰.

我们用https://www.apple.com/来说明符合ATS的请求,这个不需要我们做任何额外工作,可以直接写请求,并得到数据.

我们用https://kyfw.12306.cn/来说明不完全符合ATS的请求,12306的证书并没有经过知名CA认证(这就相当于我们后台自签名证书,没有经过知名CA认证).

首先,我们需要得到证书,12306的证书需要我们从其网站下载.

图片 14访问12306.png图片 15点击View.png图片 16导出证书.png图片 17存储为第一种格式.png图片 18命令行生成cer.png

把pem转化为cer的命令为(我的文件取和存的地址都在桌面):

$ openssl x509 -inform PEM -in ~/Desktop/kyfw.12306.cn.pem -outform DER -out ~/Desktop/kyfw_12306_cn.cer 

图片 19由pem得到cer.png

然后,把cer导入到工程中,记得勾选我们使用cer所对应的target,否则可能会出bug.

图片 20将cer导入到工程.png

由于我们是本地导入的证书,所以我们要识别证书,这需要做一些验证,还好AFNetworking极大的简化了这个步骤.

 manager.securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate]; manager.securityPolicy.validatesDomainName = YES; manager.securityPolicy.allowInvalidCertificates = YES; 

如果是使用NSURLConnection,NSURLSession或者其他网络框架,就需要自己写验证了,可以参考这篇文章.

(本人对于NSURLConnection,NSURLSession验证证书的代码没搞懂,所以抱歉,这里就没法给出原生网络请求验证的Demo了-

  • !)

接着,按照上面的教程调整plist文件,对于12306的证书,我们不太清楚它具体那里没有符合ATS,我们需要尝试.

最终,这样可以调通:

图片 21设置12306证书的Exception.png

源码:

#import "ViewController.h"#import "AFNetworking.h"@interface ViewController ()@end@implementation ViewController- viewDidLoad { [super viewDidLoad]; [self networking];}- networking { NSString * appleStr = @"https://www.apple.com/"; NSString * kyfwStr = @"https://kyfw.12306.cn/otn/"; AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager]; manager.requestSerializer = [AFHTTPRequestSerializer serializer]; manager.responseSerializer = [AFHTTPResponseSerializer serializer]; // 使用自签名证书要用以下代码来验证,其他情况要注掉// manager.securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate];// manager.securityPolicy.validatesDomainName = YES;// manager.securityPolicy.allowInvalidCertificates = YES; [manager GET:appleStr parameters:nil success:^(AFHTTPRequestOperation * _Nonnull operation, id _Nonnull responseObject) { NSLog(@"****JSON: %@", responseObject); } failure:^(AFHTTPRequestOperation * _Nullable operation, NSError * _Nonnull error) { NSLog(@"****Error: %@", error); }];}@end 

以上,我们详细列举了iOS实现https的情况,虽然内容很多,但其实,在实际开发中,需要我们做的工作并不多.总结来说,如果我们的请求符合ATS,则我们不需要做任何额外工作,如果不完全符合,比如,自签名证书,需要我们把自签名证书导入工程,调整plist文件,验证该证书即可.

HTTPS那些事(三)攻击实例与防御

由于非对称性加密的特性,就算鲍勃发送的消息被拦截了,他人没有私钥,也无法解密信件.而爱丽丝发送的消息,由于公钥是不是私密性的,可能其他人也拥有,所以爱丽丝发送的消息可能被偷窥,但是不能被修改.

下载源码

下载地址

一、什么是HTTPS

为了不让爱丽丝发送的消息被别人偷窥到,他们又想出了办法.

在说HTTPS之前先说说什么是HTTP,HTTP就是我们平时浏览网页时候使用的一种协议。HTTP协议传输的数据都是未加密的,也就是明文的,因此使用HTTP协议传输隐私信息非常不安全。为了保证这些隐私数据能加密传输,于是网景公司设计了SSL(Secure
Sockets
Layer)协议用于对HTTP协议传输的数据进行加密,从而就诞生了HTTPS。SSL目前的版本是3.0,被IETF(Internet
Engineering Task Force)定义在RFC 6101中,之后IETF对SSL
3.0进行了升级,于是出现了TLS(Transport Layer Security) 1.0,定义在RFC
2246。实际上我们现在的HTTPS都是用的TLS协议,但是由于SSL出现的时间比较早,并且依旧被现在浏览器所支持,因此SSL依然是HTTPS的代名词,但无论是TLS还是SSL都是上个世纪的事情,SSL最后一个版本是3.0,今后TLS将会继承SSL优良血统继续为我们进行加密服务。目前TLS的版本是1.2,定义在RFC
5246中,暂时还没有被广泛的使用。

他们约定还是使用对称性加密的方法,但是传递对称性加密的密钥时,使用非对称加密.怎么做呢?

对历史感兴趣的朋友可以参考http://en.wikipedia.org/wiki/Transport\_Layer\_Security,这里有对TLS/SSL详尽的叙述。

首先鲍勃向爱丽丝请求公钥,当鲍勃拿到公钥后,鲍勃随机生成了一个密钥A,并且通过爱丽丝的公钥把密钥A加密,然后发送给爱丽丝.

二、HTTPS到底安全吗?

爱丽丝拿到消息,通过私钥解密,拿到秘钥A,然后他们就通过秘钥A用对称性加密愉快的交谈了.

这个答案是肯定的,很安全。谷歌公司已经行动起来要大力推广HTTPS的使用,在未来几周,谷歌将对全球所有本地域名都启用HTTPS,用户只要在搜索前用Google帐号登录,之后所有的搜索操作都将使用TLS协议加密,见:http://thenextweb.com/google/2012/03/05/google-calls-for-a-more-secure-web-expands-ssl-encryption-to-local-domains/。

可能有刁钻的同学说了,如果当鲍勃第一次向爱丽丝请求公钥的时候,有个人假冒爱丽丝给了他公钥,那么鲍勃不就上当了.鲍勃会和假的爱丽丝聊天,然而却浑然不知.

三、HTTPS的工作原理

于是他们又双叕想到了方法来解决这个问题——CA证书.

HTTPS在传输数据之前需要客户端(浏览器)与服务端(网站)之间进行一次握手,在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议不仅仅是一套加密传输的协议,更是一件经过艺术家精心设计的艺术品,TLS/SSL中使用了非对称加密,对称加密以及HASH算法。握手过程的简单描述如下:

什么是CA证书呢,CA是个机构,而证书就是CA机构把你的公钥和你的你的一些信息通过他私钥加密出来的东西.

1.浏览器将自己支持的一套加密规则发送给网站。

爱丽丝拿着她的公钥去CA,CA把她得公钥和她的一些基本信息通过CA的私钥加密成CA证书.然后当鲍勃请求她公钥的时候,她回复鲍勃的是CA证书.
鲍勃拿到证书,会用CA提供的公钥解密,如果解密成功,则证明这公钥肯定是爱丽丝给的.这样就避免了有人冒充爱丽丝和他交谈.

2.网站从中选出一组加密算法与HASH算法,并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址,加密公钥,以及证书的颁发机构等信息。

上述文字描述的很不规范,只是大概描述了HTTPS中的一些点,权当自己的一个记录.
(完)

3.获得网站证书之后浏览器要做以下工作:

a)
验证证书的合法性(颁发证书的机构是否合法,证书中包含的网站地址是否与正在访问的地址一致等),如果证书受信任,则浏览器栏里面会显示一个小锁头,否则会给出证书不受信的提示。

b)
如果证书受信任,或者是用户接受了不受信的证书,浏览器会生成一串随机数的密码,并用证书中提供的公钥加密。

c)
使用约定好的HASH计算握手消息,并使用生成的随机数对消息进行加密,最后将之前生成的所有信息发送给网站。

4.网站接收浏览器发来的数据之后要做以下的操作:

a)
使用自己的私钥将信息解密取出密码,使用密码解密浏览器发来的握手消息,并验证HASH是否与浏览器发来的一致。

b) 使用密码加密一段握手消息,发送给浏览器。

5.浏览器解密并计算握手消息的HASH,如果与服务端发来的HASH一致,此时握手过程结束,之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。

这里浏览器与网站互相发送加密的握手消息并验证,目的是为了保证双方都获得了一致的密码,并且可以正常的加密解密数据,为后续真正数据的传输做一次测试。另外,HTTPS一般使用的加密与HASH算法如下:

非对称加密算法:RSA,DSA/DSS

对称加密算法:AES,RC4,3DES

HASH算法:MD5,SHA1,SHA256

其中非对称加密算法用于在握手过程中加密生成的密码,对称加密算法用于对真正传输的数据进行加密,而HASH算法用于验证数据的完整性。由于浏览器生成的密码是整个数据加密的关键,因此在传输的时候使用了非对称加密算法对其加密。非对称加密算法会生成公钥和私钥,公钥只能用于加密数据,因此可以随意传输,而网站的私钥用于对数据进行解密,所以网站都会非常小心的保管自己的私钥,防止泄漏。

TLS握手过程中如果有任何错误,都会使加密连接断开,从而阻止了隐私信息的传输。正是由于HTTPS非常的安全,攻击者无法从中找到下手的地方,于是更多的是采用了假证书的手法来欺骗客户端,从而获取明文的信息,但是这些手段都可以被识别出来,我将在后续的文章进行讲述。不过2010年还是有安全专家发现了TLS
1.0协议处理的一个漏洞:http://www.theregister.co.uk/2011/09/19/beast\_exploits\_paypal\_ssl/,实际上这种称为BEAST的攻击方式早在2002年就已经被安全专家发现,只是没有公开而已。目前微软和Google已经对此漏洞进行了修复。见:http://support.microsoft.com/kb/2643584/en-ushttps://src.chromium.org/viewvc/chrome?view=rev&revision=90643

本文来自转发

发表评论

电子邮件地址不会被公开。 必填项已用*标注