Network - SSL/TLS的基本概念

对称加密与非对称加密

加密---明文变成密文;解密---密文变为明文。在这两个过程中,都需要密钥。

对称密钥加密(共享密钥)
指的是双方共同拥有使用完全相同的单个key, 这种Key既用于加密,也用于解密。
对称加密算法的原理很容易理解,通信一方用KEY加密明文,另一方收到之后用同样的KEY来解密就可以得到明文。
对称密钥加密是加密大量数据的一种行之有效的方法。 
最常见的是DES. DES3, RC4等。
 
非对称加密(公钥加密)
指双方用不同的KEY加密和解密明文,通信双方都要有自己的公共密钥和私有密钥。公钥和私钥这两个密钥在数学上是相关的(素数积求因子的原理)。
公钥(公共密钥)----- 用来加密和验证签名,是给大家用的,在通信双方之间公开传递,在公用储备库中发布,也可通过电子邮件发布,或者通过网站提供下载等。
私钥(私有密钥)----- 保密的,仅为自己所知,用来进行解密和签名;
公钥和私钥都可以用来加密数据,用对应的另一个解开加密数据。也就是说用公钥加密的内容只能用私钥解密,用私钥加密的内容只能用公钥解密。
公钥加密数据,然后私钥解密的情况被称为加密解密,
私钥加密数据,公钥解密一般被称为签名和验证签名.
 
不对称加密主要局限在于速度相对较低。实际上,通常仅在关键时刻才使用公钥算法,如在实体之间交换对称密钥时,或者在签署一封邮件的散列时。
常用的不对称加密一般有RSA、 DSA、 DH等。一般使用RSA。
 
公共密钥交换(key exchange)
通信双方彼此交换公钥。
公共密钥交换之后双方就分别用对方的公共密钥加密发送的数据,用自己的私有密钥解密接收的数据。
因为公共密钥和私有密钥的特点是,经过其中任何一把加密过的明文,只能用另外一把才能够解开,这样最大程度保证了安全性.
 
验证机制(签名和验证签名)
当A传送数据给B时,会以自己的私钥做签名,由于私钥仅为自己所有,这样就产生了别人无法生成的文件,也就形成了数字签名。
当B接收来自A的数据,用A的公钥验证签名,便可确认数据是由 A 发出来的了。

密钥协商的形象化比喻
假设A与B通信,A是SSL客户端,B是SSL服务器端,加密后的消息放在方括号[]里,以突出明文消息的区别。双方的处理动作的说明用圆括号()括起。

A:我想和你安全的通话,我这里的对称加密算法有DES,RC5,密钥交换算法有RSA和DH,摘要算法有MD5和SHA。

B:我们用DES-RSA-SHA这对组合好了。这是我的证书,里面有我的名字和公钥,你拿去验证一下我的身份

    (把证书发给A)。

      目前没有别的可说的了。

A:(查看证书上B的名字是否无误,并通过手头早已有的CA的证书验证了B的证书的真实性,如果其中一项有误,发出警告并断开连接,这一步保证了B的公钥的真实性)

      (产生一份秘密消息,这份秘密消息处理后将用作加密密钥,加密初始化向量(IV)和hmac的密钥。将这份秘密消息-协议中称为per_master_secret-用B的公钥加密,封装成称作ClientKeyExchange的消息。由于用了B的公钥,保证了第三方无法窃听)

        我生成了一份秘密消息,并用你的公钥加密了,给你(把ClientKeyExchange发给B)注意,下面我就要用加密的办法给你发消息了!

       (将秘密消息进行处理,生成加密密钥,加密初始化向量和hmac的密钥)

         [我说完了]

B:(用自己的私钥将ClientKeyExchange中的秘密消息解密出来,然后将秘密消息进行处理,生成加密密钥,加密初始化向量和hmac的密钥,这时双方已经安全的协商出一套加密办法了)

       注意,我也要开始用加密的办法给你发消息了!

        [我说完了]

A: [我的秘密是...]

B: [其它人不会听到的...]

参考信息

SSL/TLS协议运行机制的概述
http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
SSL/TLS原理详解
http://segmentfault.com/a/1190000002554673

数字证书及CA的扫盲介绍

OpenSSL 与 SSL 数字证书概念贴
http://segmentfault.com/a/1190000002568019

Linux的加密认证功能以及openssl详解
http://lanlian.blog.51cto.com/6790106/1281720

数据包分析

使用wireshark观察SSL/TLS握手过程--双向认证/单向认证 
密码套件
         cipherSuite         TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
“TLS” 自然是指TLS协议。
“ECDHE” 是说使用带有短暂性密钥的椭圆曲线Diffie-Hellman密钥交换(也就是说要为每个会话创建新密钥并且事后也不会记下来)。
“RSA”表明用RSA 非对称加密保护TLS握手的安全。
“AES_128_GCM” 是说在密码块链接模式中用带有256位密钥的AES 非对称加密保护真正的数据交换。 “GCM”(伽罗瓦/计数器模式)。
“SHA384” 表明用 SHA384位 安全哈希算法

SSL Tools

https://www.trustasia.com/tools/

http://web.chacuo.net/netsslcsr

协议概述

缩写 名称 默认端口 安全策略 描述
HTTP Hyper Text Transfer Protocol(超文本传输协议)
TCP80 HTTP 协议是明文的,传输内容会被嗅探和篡改。
客户端浏览器或其他程序与Web服务器之间的应用层通信协议
SSL/TLS
Secure Sockets Layer(安全套接层)
Transport Layer Security(传输层安全)
TCP443 1)认证用户和服务器,确保数据发送到正确的客户机和服务器;2)加密数据以防止数据中途被窃取;3)维护数据的完整性,确保数据在传输过程中不被改变。
SSL(Secure Socket Layer)是netscape公司设计的主要用于web的安全传输协议,在WEB上广泛应用。
IETF(www.ietf.org)将SSL作了标准化,即RFC2246,并将其称为TLS(Transport Layer Security)。
从技术上讲,TLS1.0与SSL3.0的差别非常微小,例如SSL3.3对应TLS1.2,通常并列称呼。
SSL/TLS 可以强化一些常用应用层协议(比如:FTP、SMTP、POP、Telnet)的安全性。 SSL与TLS介于应用层和TCP层之间,在传输层对网络连接进行加密。应用层数据不再直接传递给传输层,而是传递给SSL层,SSL层对从应用层收到的数据进行加密,并增加自己的SSL头,从而为网络通信及数据完整性提供安全支持。
HTTPS
HTTP over SSL
TCP443
实际上是在原有的 HTTP 数据外面加了一层 SSL 的封装。HTTP 协议原有的 GET、POST 之类的机制,基本上原封不动。
可以简单理解为“HTTP 协议”和“SSL/TLS 协议”的组合
 
 
 
 
 
 
 
 
 
 
 
 
 
 

转载于:https://www.cnblogs.com/anliven/p/6015432.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值