由于面试笔试中经常会涉及到https及加密解密相关的技术,故此下面我对相关加解密知识进行简单总结,主要是剖析https背后的运行机制。先来了解下有关加解密的基础技术,如MD5 数字签名 非对称密钥加密等。
MD5到底有什么用 ?
当我们下载了文件后,如果想知道下载的这个文件和网站的原始文件是否一模一样,就可以给自己下载的文件做个MD5校验。如果得到的MD5值和网站公布的相同,可确认所下载的文件是完整的。如有不同,说明你下载的文件是不完整的:要么就是在网络下载的过程中出现错误,要么就是此文件已被别人修改。为防止他人更改该文件时放入病毒,最好不要使用。 当我们用E-mail给好友发送文件时,可以将要发送文件的MD5值告诉对方,这样好友收到该文件以后即可对其进行校验,来确定文件是否安全。 再比如:在刚安装好系统后可以给系统文件做个MD5校验,过了一段时间后如果你怀疑某些文件被人换掉,那么就可以给那些被怀疑的文件做个MD5校验,若和从前得到的MD5校验码不一样,那么就可以肯定是有问题的。 MD5就好比每个人的指纹都是唯一的一样,文件的MD5值也是唯一的,效验MD5就是用来确保文件在传输过程中未被修改用的有的网站在提供下载的同时还提供MD5值,你可以去下一个MD5效验工具,这样下别的东西完成后,就可以效验一下。
另外: MD5将任意长度的“字节串”变换成一个128bit的大整数,并且它是一个不可逆的字符串变换算法,换句话说就是,即使你看到源程序和算法描述,也无法将一个MD5的值变换回原始的字符串,从数学原理上说,是因为原始的字符串有无穷多个,这有点象不存在反函数的数学函数。
MD5的典型应用是对一段Message(字节串)产生fingerprint(指纹),以防止被“篡改”。举个例子,你将一段话写在一个叫 readme.txt文件中,并对这个readme.txt产生一个MD5的值并记录在案,然后你可以传播这个文件给别人,别人如果修改了文件中的任何内容,你对这个文件重新计算MD5时就会发现。如果再有一个第三方的认证机构,用MD5还可以防止文件作者的“抵赖”,这就是所谓的数字签名应用。
MD5广泛用于加密和解密技术上,在很多操作系统中,用户的密码是以MD5值(或类似的其它算法)的方式保存的,用户Login的时候,系统是把用户输入的密码计算成MD5值,然后再去和系统中保存的MD5值进行比较,而系统并不“知道”用户的密码是什么。MD5是个单向加密的过程是单向散列算法。单向散列加密是指不同输入长度的信息进行散列计算,得到固定长度的输出,这个散列计算过程是单向的,即不同通过对固定长度的输出进行计算从而获得输入信息。
1)对称加密是指:加密和解密使用的是同一个密钥(获取可以互相推算)。DES算法 RC算法。
2)非对称加密:加密和解密使用的密钥不是同一个密钥,其中一个对外界公开,被称作公钥,另一个只有所有者知道,即私钥。理论上 不可能通过公钥计算得到私钥。常见算法有RSA算法。
Https传输中浏览器使用的数字证书实质上是经过权威机构CA认证的非对称加密的公钥。
3)单向散列加密:通过对不同输入长度的信息进行散列hash计算,得到固定长度的输出,这个散列计算过程是单向的,即不同通过对固定长度的输出进行计算从而获得输入信息。常见算法有:MD5 SHA
非对称加密技术通常用在信息安全传输数字签名场合。
信息发送者A通过公开渠 道获得信息接受者B的公钥,对提交信息进行加密,然后通过非安全传输通道将密文信息发送给B,B得到密文信息后,用自己的私钥对信息进行解密,获得原始的明文信息,即使密文信息在传输过程中被窃取,窃取者没有解密密钥也无法明文。
数字签名的过程正好相反,签名者用自己的私钥对信息进行加密,然后发送给对方,接收方用签名者的公钥对信息进行解密,获取原始明文信息,由于私钥只有签名者拥有,因此该信息是不可抵赖的,具有签名的信息。可以用来验证信息数据的完整性。
实际应用中,常常会混合使用对称加密和非对称加密(如https).先使用非对称加密技术对对称密钥进行安全传输,然后使用对称加密技术进行信息加密和交换。而有时,对同一个数据两次使用非对称加密,可同时实现信息安全传输与数字签名的目的。
数字签名技术是将摘要信息用发送者的私钥加密,与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息,然后用HASH函数对收到的原文产生一个摘要信息,与解密的摘要信息对比。如果相同,则说明收到的信息是完整的,在传输过程中没有被修改,否则说明信息被修改过,因此数字签名能够验证信息的完整性。数字签名有两种功效:一是能确定消息确实是由发送方签名并发出来的,因为别人假冒不了发送方的签名即具有不可抵赖性。二是数字签名能确定消息的完整性。因为数字签名的特点是它代表了文件的特征,文件如果发生改变,数字摘要的值也将发生变化。不同的文件将得到不同的数字摘要。一次数字签名涉及到一个哈希函数、发送者的公钥、发送者的私钥。”
数字签名是非对称密钥加密技术与数字摘要技术的应用
实际使用过程为:“发送报文时,发送方用一个哈希函数从报文文本中生成报文摘要,然后用自己的私人密钥对这个摘要进行加密,这个加密后的摘要将作为报文的数字签名和报文一起发送给接收方,接收方首先用与发送方一样的哈希函数从接收到的原始报文中计算出报文摘要,接着再用发送方的公用密钥来对报文附加的数字签名进行解密,如果这两个摘要相同、那么接收方就能确认该数字签名是发送方的。
加密和数字签名针对公钥(加x)和私钥(数字xx)的使用过程正好是相反的。
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议。在URL前加https://前缀表明是用SSL加密的。我们的电脑与服务器之间收发的信息传输将更加安全。Web服务器启用SSL需要获得一个服务器证书并将该证书与要使用SSL的服务器绑定。 http和https使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。
SSL(Security Socket Layer)全称是加密套接字协议层,它位于HTTP协议层和TCP协议层之间,即处于传输层之上。用于建立用户与服务器之间的加密通信,确保所传递信息的安全性,同时SSL安全机制是依靠数字证书来实现的。
(https)SSL基于公用密钥和私人密钥,用户使用公用密钥来加密数据,但解密数据必须使用相应的私人密钥。使用SSL安全机制的通信过程如下:用户与IIS服务器建立连接后,服务器会把数字证书与公用密钥发送给用户,用户端生成会话密钥(即对称密钥),并用公共密钥对会话密钥进行加密,然后传递给服务器,服务器端用私人密钥进行解密,这样,用户端和服务器端就建立了一条安全通道,只有SSL允许的用户才能与IIS服务器进行通信。
可以看出,Https的工作过程原理实际上是非对称密钥加解密(先)和对称密钥加解密(后)的结合。
客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤,
(1)客户使用https的URL访问Web服务器,要求与Web服务器建立SSL连接。
(2)Web服务器收到客户端请求后,会将网站的证书信息(证书中包含公钥)传送一份给客户端。
(3)客户端的浏览器与Web服务器开始协商SSL连接的安全等级,也就是信息加密的等级。
(4)客户端的浏览器根据双方同意的安全等级,建立会话密钥,然后利用网站的公钥将会话密钥加密,并传送给网站。
(5)Web服务器利用自己的私钥解密出会话密钥。
(6)Web服务器利用会话密钥加密与客户端之间的通信。
注意:证书中心CA用自己的私钥,对服务器的公钥和一些相关信息一起加密,生成"数字证书"(Digital Certificate)。
其实这也是SSL握手的机制:
SSL 是一个安全协议,它提供使用TCP/IP的通信应用程序间的隐私与完整性。因特网的 超文本传输协议 (HTTP)使用 SSL 来实现安全的通信。在客户端与服务器间传输的数据是通过使用对称算法(如 DES或 RC4)进行加密的。公用密钥算法(通常为 RSA)是用来获得加密密钥交换和数字签名的,此算法使用服务器的SSL数字证书中的公用密钥。有了服务器的SSL数字证书,客户端也可以验证服务器的身份。SSL协议的版本 1和 2只提供服务器认证。版本 3添加了客户端认证,此认证同时需要客户端和服务器的数字证书。SSL连接总是由客户端启动的。在SSL会话开始时执行 SSL握手。此握手产生会话的密码参数。SSL的客户端与服务器端的认证握手如下图所示:
HTTPS和HTTP的区别:
https协议需要到ca申请证书,一般免费证书很少,需要交费。
http是超文本传输协议,信息是明文传输,https则是具有安全性的ssl加密传输协议
http和https使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443。
http的连接很简单,是无状态的
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议要比http协议安全
HTTPS解决的问题:
1 . 信任主机的问题.采用https的server必须从CA申请一个用于证明服务器用途类型的证书.改证书只有用于对应的server的时候,客户度才信任次主机.所以目前所有的银行系统网站,关键部分应用都是https的.客户通过信任该证书,从而信任了该主机.其实这样做效率很低,但是银行更侧重安全.这一点对我们没有任何意义,我们的server ,采用的证书不管自己issue还是从公众的地方issue,客户端都是自己人,所以我们也就肯定信任该server.
2 . 通讯过程中的数据的泄密和被窜改
1. 一般意义上的https,就是 server有一个证书.
a) 主要目的是保证server就是他声称的server.这个跟第一点一样.
b) 服务端和客户端之间的所有通讯,都是加密的.
i. 具体讲,是客户端产生一个对称的密钥,通过server的证书来交换密钥.一般意义上的握手过程.
ii. 加下来所有的信息往来就都是加密的.第三方即使截获,也没有任何意义.因为他没有密钥.当然窜改也就没有什么意义了.
2. 少许对客户端有要求的情况下,会要求客户端也必须有一个证书.
a) 这里客户端证书,其实就类似表示个人信息的时候,除了用户名/密码,还有一个CA认证过的身份.应为个人证书一般来说上别人无法模拟的,所有这样能够更深的确认自己的身份.
b) 目前少数个人银行的专业版是这种做法,具体证书可能是拿U盘作为一个备份的载体.
HTTPS 一定是繁琐的.
a) 本来简单的http协议,一个get一个response.由于https要还密钥和确认加密算法的需要.单握手就需要6/7个往返.
i. 任何应用中,过多的round trip 肯定影响性能.
b) 接下来才是具体的http协议,每一次响应或者请求,都要求客户端和服务端对会话的内容做加密/解密.
i. 尽管对称加密/解密效率比较高,可是仍然要消耗过多的CPU,为此有专门的SSL芯片.如果CPU信能比较低的话,肯定会降低性能,从而不能serve更多的请求.
ii. 加密后数据量的影响.所以,才会出现那么多的安全认证提示
数字证书digital certificate用于为客户端用户认证web站点即服务器,以防止恶意站点冒充成其他WEB站点。即用于服务器端发送给客户端,以确定服务器端的真实性真实身份。
认证机构(即证书中心CA)A签署的数字证书由一个公钥(其实保存在客户端浏览器中)Ka和一个可以用公钥ka解密的加密文本E构成。该加密文本包括该证书签发给的团体名次及它的公钥Kc.
认证中心CA的公钥保存在客户端WEB浏览器中,CA(用CA其私钥为WEB站点服务器)签署的数字证书可以使用客户端保存的公钥来验证。且注意:数字证书中包裹着着服务器站点的公钥(即上面所提的Kc)。