码出高效:Java开发手册-第1章(8)-阿里云开发者社区

开发者社区> 博文视点Broadview> 正文

码出高效:Java开发手册-第1章(8)

简介: 本书源于影响了全球250万名开发工程师的《阿里巴巴Java开发手册》,作者静心沉淀,对Java规约的来龙去脉进行了全面而彻底的内容梳理。本书以实战为中心,以新颖的角度全面阐述面向对象理论,逐步深入地探索怎样成为一位优秀开发工程师。比如:如何驾轻就熟地使用各类集合框架;如何得心应手地处理高并发多线程问题;如何顺其自然地写出可读性强、可维护性好的优雅代码。 本书旁征博引、文风轻松,秉持“图胜于表,表胜于言”的理念,深入浅出地将计算机基础、面向对象思想、JVM探源、数据结构与集合、并发与多线程、单元测试等知识客观、立体地呈现出来。紧扣学以致用......
+关注继续查看

1.6.5 HTTPS

在谍战剧里,情报如何不被截获,不被破译,几乎是全剧的主线剧情之一。某电台通过某个频道发送一串数字,然后潜伏人员一般会拿密码本,译码后得到原文。这个密码本就是对称加密中的密钥,发送方和接收方按照密码本分别进行加密和解密工作。如果密码本被敌人截获,则后果极为严重,通常能够做的也就是更换密码本。

早期计算机都是单机状态,保证数据的安全依赖于加密算法的可靠性。如果加密算法可靠,即使存储介质被窃取,对方想把密文恢复明文也是十分困难的。DES 加密算法是一种对称加密算法,它几乎让破解者无法找到规律,即使暴力破解也很难还原出明文。

发展到网络时代,整个网络中最频繁、最重要的操作就是网络中各终端之间的通信。在传输层本身不会做任何的加密,这就好比一辆满载黄金的马车在驿道奔驰,很难不让网络上的黑客视而不见。如何保证通信之间数据传输的安全性,成为了计算机网络时代最重要的安全课题。说到对网络传输数据的加密,必须要先说安全套接字层(Secure Socket Layer,SSL)。SSL 协议工作于传输层与应用层之间,为应用提供数据的加密传输。而HTTPS 的全称是HTTP over SSL,简单的理解就是在之前的HTTP传输上增加了SSL 协议的加密能力。

我们可以通过对称加密算法对数据进行加密,比如DES,即一个主站与用户之间可以使用相同的密钥对传输内容进行加解密。是否可以认为这样就完全没有风险呢?答案显然是否定的。因为密钥几乎没有什么保密性可言,如果与每一个用户之间都约定一个独立的密钥,如何把密钥传输给对方,又是一个安全难题。在互联网上,IP 报文好比官道上运送粮草、黄金、物资的载体,很容易被人盯上,密钥本身如果被盗,那么再复杂的密钥也是摆设。自然的想法是在密钥之上再加密,这就是递归的穷举问题了。

有没有一种方式,使报文被截取之后,黑客依然无计可施呢?一种全新的算法RSA 出现了。它把密码革命性地分成公钥和私钥,由于两个密钥并不相同,所以称为非对称加密。私钥是用来对公钥加密的信息进行解密的,是需要严格保密的。公钥是对信息进行加密,任何人都可以知道,包括黑客。

非对称加密的安全性是基于大质数分解的困难性,在非对称的加密中公钥和私钥是一对大质数函数。计算两个大质数的乘积是简单的,但是这个过程的逆运算(即将这个乘积分解为两个质数)是非常困难的。而在RSA 的算法中,从一个公钥和密文中解密出明文的难度等同于分解两个大质数的难度。因此在实际传输中,可以把公钥发给对方。一方发送信息时,使用另一方的公钥进行加密生成密文。收到密文的一方再用私钥进行解密,这样一来,传输就相对安全了。

但是非对称加密并不是完美的,它有一个很明显的缺点是加密和解密耗时长,只适合对少量数据进行处理。回到前面的例子中,我们担心对称加密中的密钥安全问题,那么将密钥的传输使用非对称加密就完美地解决了这个问题。实际上,HTTPS 也正是通过这样一种方式来建立安全的SSL 连接的。按照上述逻辑,用户甲与用户乙进行非对称加密传输的过程如下:

(1)甲告诉乙,使用RSA 算法进行加密。乙说,好的。

(2)甲和乙分别根据RSA 生成一对密钥,互相发送公钥。

(3)甲使用乙的公钥给乙加密报文信息。

(4)乙收到信息,并用自己的密钥进行解密。

(5)乙使用同样方式给甲发送信息,甲使用相同方式进行解密。

这个过程,看起来似乎无懈可击,但是在TCP/IP 里,端到端的通信,路途遥远,夜长梦多。在(2)中,如果甲的送信使者中途被强盗截住,在严刑拷打之下,强盗知道使者是去送公钥的,虽然没有办法破解甲的加密信息,但是可以把这个使者关起来,自己生成一对密钥,然后冒充甲的使者到乙家,把自己的公钥给乙。乙信了,把银行卡密码、存款金额统统告诉了中间的强盗。

所以,在解决了加密危机之后又产生了信任危机。如何解决信任问题呢?如果有一个具有公信力的组织来证明身份,这个问题就得到了解决。CA(Certificate Authority)就是颁发HTTPS 证书的组织。HTTPS 是当前网站的主流文本传输协议,在基于HTTPS 进行连接时,就需要数字证书。如图1-28 所示,可以看到协议版本、签名方案、签发的组织是GlobalSign,这个证书的有效期至2018 年10 月31 日。

28.jpg

图1-28 CA 数字证书

访问一个HTTPS 的网站的大致流程如下:

(1)浏览器向服务器发送请求,请求中包括浏览器支持的协议,并附带一个随机数。

(2)服务器收到请求后,选择某种非对称加密算法,把数字证书签名公钥、身份信息发送给浏览器,同时也附带一个随机数。

(3) 浏览器收到后,验证证书的真实性,用服务器的公钥发送握手信息给服务器。

(4)服务器解密后,使用之前的随机数计算出一个对称加密的密钥,以此作为加密信息并发送。

(5)后续所有的信息发送都是以对称加密方式进行的。

我们注意到在证书的信息中出现了传输层安全协议(Transport Layer Security,TLS)的概念。这里先解释TLS 和SSL 的区别。TLS 可以理解成SSL 协议3.0 版本的升级,所以TLS 的1.0 版本也被标识为SSL 3.1 版本。但对于大的协议栈而言,SSL 和TLS 并没有太大的区别,因此在Wireshark 里,分层依然用的是安全套接字层(SSL)标识。

在整个HTTPS 的传输过程中,主要分为两部分:首先是HTTPS 的握手,然后是数据的传输。前者是建立一个HTTPS 的通道,并确定连接使用的加密套件及数据传输使用的密钥。而后者主要使用密钥对数据加密并传输。

首先来看HTTPS 是如何进行握手的,如图1-29 所示是一个完整的SSL 数据流和简单流程。

image.png

29.jpg

图1-29 HTTPS 连接建立过程

第一,客户端发送了一个Client Hello 协议的请求:在Client Hello 中最重要的信息是Cipher Suites 字段,这里客户端会告诉服务端自己支持哪些加密的套件。比如在这次SSL 连接中,客户端支持的加密套件协议如图1-30 所示。

image.png

图1-30 Cipher Suites

第二,服务端在收到客户端发来的Client Hello 的请求后,会返回一系列的协议数据,并以一个没有数据内容的Server Hello Done 作为结束。这些协议数据有的是单独发送,有的则是合并发送,这里分别解释下几个比较重要的协议,如图1-31 所示。

image.png

图1-31 SSL 协议

(1)Server Hello 协议。主要告知客户端后续协议中要使用的TLS 协议版本,这个版本主要和客户端与服务端支持的最高版本有关。比如本次确认后续的TLS 协议版本是TLSv1.2,并为本次连接分配一个会话ID(Session ID)。此外,还会确认后续采用的加密套件(Cipher Suite),这里确认使用的加密套件为TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。该加密套件的基本含义为:使用非对称协议加密(RSA)进行对称协议加密(AES)密钥的加密,并使用对称加密协议(AES)进行信息的加密。

(2)Certificate 协议。主要传输服务端的证书内容。

(3)Server Key Exchange。如果在Certificate 协议中未给出客户端足够的信息,则会在Server Key Exchange 进行补充,如图1-32 所示。比如在本次连接中Certificate未给出证书的公钥(Public Key),这个公钥的信息将会通过Server Key Exchange 发送给客户端。

image.png

图1-32 Server Key Exchange

(4)Certificate Request。这个协议是一个可选项,当服务端需要对客户端进行证书验证的时候,才会向客户端发送一个证书请求(Certificate Request)。

(5)最后以Server Hello Done 作为结束信息,告知客户端整个Server Hello过程结束。

第三,客户端在收到服务端的握手信息后,根据服务端的请求,也会发送一系列的协议。

(1)Certificate。它是可选项。因为上文中服务端发送了Certificate Request 需要对客户端进行证书验证,所以客户端要发送自己的证书信息。

(2)Client Key Exchange。它与上文中Server Key Exchange 类似,是对客户端Certificate 信息的补充,在本次请求中同样是补充了客户端证书的公钥信息,如图1-33所示。

image.png

图1-33 Client Key Exchange

(3)Certification Verity。对服务端发送的证书信息进行确认。

(4)Change Cipher Spec。该协议不同于其他握手协议(Handshake Protocol),而是作为一个独立协议告知服务端,客户端已经接收之前服务端确认的加密套件,并会在后续通信中使用该加密套件进行加密。

(5)Encrypted Handshake Message。用于客户端给服务端加密套件加密一段Finish 的数据,用以验证这条建立起来的加解密通道的正确性。

第四,服务端在接收客户端的确认信息及验证信息后,会对客户端发送的数据进行确认,这里也分为几个协议进行回复。

(1)Change Cipher Spec。通过使用私钥对客户端发送的数据进行解密,并告知后续将使用协商好的加密套件进行加密传输数据。

(2)Encrypted Handshake Message。与客户端的操作相同,发送一段Finish 的加密数据验证加密通道的正确性。

最后,如果客户端和服务端都确认加解密无误后,各自按照之前约定的Session Secret 对Application Data 进行加密传输。


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
PO,VO,DAO,BO,POJO 之间的区别你懂吗?
value object:值对象。 通常用于业务层之间的数据传递,由new创建,由GC回收。
7 0
排名前 16 的 Java 工具类,哪个你没用过?
在Java中,实用程序类是定义一组执行通用功能的方法的类。 这篇文章展示了最常用的Java实用工具类及其最常用的方法。类列表及其方法列表均按受欢迎程度排序。数据基于从GitHub随机选择的50,000个开源Java项目。 希望您可以通过浏览列表来了解
8 0
ECS使用感受
阿里云服务器初体验
3 0
ECS初体验
esc简单的初体验
4 0
Java 强、弱、软、虚,你属于哪一种?
Java中的四种引用 Java中有四种引用类型:强引用、软引用、弱引用、虚引用。
3 0
Java 强、弱、软、虚,你属于哪一种?
Java中的四种引用 Java中有四种引用类型:强引用、软引用、弱引用、虚引用。
3 0
微服务架构 | *2.3 Spring Cloud 启动及加载配置文件源码分析(以 Nacos 为例)
Spring Cloud 要实现统一配置管理,需要解决两个问题:如何获取远程服务器配置和如何动态更新配置;在这之前,我们先要知道 Spring Cloud 什么时候给我们加载配置文件;
3 0
微服务架构 | *2.4 Nacos 获取配置与事件订阅机制的源码分析
为方便理解与表达,这里把 Nacos 控制台和 Nacos 注册中心称为 Nacos 服务器(就是 web 界面那个),我们编写的业务服务称为 Nacso 客户端; 由于篇幅有限,这里将源码分析分为上下两篇,其中上篇讲获取配置与事件订阅机制,下篇讲长轮询定时机制;
4 0
ECS使用体验
使用阿里云服务器搭建个人博客网站
4 0
C# 同步 异步 回调 状态机 async await Demo
C# 同步 异步 回调 状态机 async await Demo 我们项目的客户端和服务端通信用的是WCF,我就想,能不能用异步的方式调用WCF服务呢?或者说能不能用async await的方式调用WCF服务呢?
6 0
+关注
博文视点Broadview
博文视点( Broadview )是电子工业出版社下属旗舰级子公司。在IT出版领域打磨多年,以敏锐眼光、独特视角密切关注技术发展趋势及变化,致力于将技术大师之优秀思想、一线专家之一流经验集结成书,为众多朋友奉献经典著作,助力个人、团队成长。
55
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载