SSL原理解密
RSA公钥加密在计算机产业中被广泛使用在认证和加密。可以从RSA Data Security Inc.获得的RSA公钥加密许可证。公钥加密是使用一对非对称的密码加密或解密的方法。每一对密码由公钥和私钥组成。公钥被广泛发布。私钥是隐密的，不公开。用公钥加密的数据只能够被私钥解密。反过来，使用私钥加密的数据只能用公钥解密。这个非对称的特性使得公钥密很有用。使用公钥加密法认证
认证是一个身份认证的过程。在下列例子中包括甲和乙，公钥加密会非常轻松地校验身份。符号{数据} key意味着"数据"已经使用密码加密或解密。假如甲想校验乙的身份。乙有一对密码，一个是公开的，另一个是私有的。乙透露给甲他的公钥。甲产生一个随机信息发送给乙。 甲——〉乙：random-message
乙使用他的私钥加密消息，返回甲加密后的消息。 乙——〉甲：{random-message}乙的私钥
甲收到这个消息然后使用乙的以前公开过的公钥解密。他比较解密后的消息与他原先发给乙的消息。如果它们完全一致，就会知道在与乙说话。任意一个中间人不会知道乙的私钥，也不能正确加密甲检查的随机消息。
除非你清楚知道你加密的消息。用私钥加密消息，然后发送给其他人不是一个好主意。因为加密值可能被用来对付你，需要注意的是：因为只有你才有私钥，所以只有你才能加密消息。所以，代替加密甲发来的原始消息，乙创建了一个信息段并且加密。信息段取自随机消息（random-message）并具有以下有用的特性：
1. 这个信息段难以还原。任何人即使伪装成乙，也不能从信息段中得到原始消息；
2. 假冒者将发现不同的消息计算出相同的信息段值；
3. 使用信息段，乙能够保护自己。他计算甲发出的随机信息段，并且加密结果，并发送加密信息段返回甲。甲能够计算出相同的信息段并且解密乙的消息认证乙。
这个技术仅仅描绘了数字签名。通过加密甲产生的随机消息，乙已经在甲产生的消息签名。因此我们的认证协议还需要一次加密。一些消息由乙产生：
甲——〉乙：你好，你是乙么?
乙——〉甲：甲，我是乙
{信息段[甲，我是乙] } 乙的私钥
当你使用这个协议，乙知道他发送给乙的消息，他不介意在上面签名。他先发送不加密的信息，"甲，我是乙。"，然后发送信息段加密的消息版本。甲可以非常方便地校验乙就是乙，同时，乙还没有在他不想要的信息上签名。
提交公钥
那么，乙怎样以可信的方式提交他的公钥呢？看看认证协议如下所示：
甲——〉乙：你好
乙——〉甲：嗨，我是乙，乙的公钥
这是网络上看到的ssl的原理,有一段不理解,拿来问大家
除非你清楚知道你加密的消息。用私钥加密消息，然后发送给其他人不是一个好主意。因为加密值可能被用来对付你，需要注意的是：因为只有你才有私钥，所以只有你才能加密消息。所以，代替加密甲发来的原始消息，乙创建了一个信息段并且加密。信息段取自随机消息（random-message）并具有以下有用的特性：
1. 这个信息段难以还原。任何人即使伪装成乙，也不能从信息段中得到原始消息；
2. 假冒者将发现不同的消息计算出相同的信息段值；
3. 使用信息段，乙能够保护自己。他计算甲发出的随机信息段，并且加密结果，并发送加密信息段返回甲。甲能够计算出相同的信息段并且解密乙的消息认证乙。
____________用私钥加密消息，然后发送给其他人不是一个好主意。文中说 乙创建了一个信息段并且加密。信息段取自随机消息（random-message）并具有以下有用的特性：......
取甲的消息的片段签名?这里是基于怎样一种机制?
--------------------编程问答-------------------- 换一种方式问问题
这个技术仅仅描绘了数字签名。通过加密甲产生的随机消息，乙已经在甲产生的消息签名。因此我们的认证协议还需要一次加密。一些消息由乙产生：
甲——〉乙：你好，你是乙么?
乙——〉甲：甲，我是乙
{信息段[甲，我是乙] } 乙的私钥
___________乙 不愿意对"你好，你是乙么? "这句话签名,乙用乙的私钥 签的是
"信息段[甲，我是乙]",这是一个什么东西?是信息段&[甲，我是乙] 还是其他什么?
为什么 "假冒者将发现不同的消息计算出相同的信息段值；"?
--------------------编程问答-------------------- mark --------------------编程问答-------------------- mark --------------------编程问答-------------------- mark --------------------编程问答-------------------- too --------------------编程问答-------------------- mark --------------------编程问答-------------------- mark --------------------编程问答-------------------- 好贴 --------------------编程问答-------------------- mark
--------------------编程问答-------------------- 好帖 --------------------编程问答-------------------- 前段时间一个同事的数据资料文件(word和excel文件都有)自己加了密后,不知怎么,删除掉原来的用户帐户后,原来的数据资料文件一个也打不开了.不知道是否与此类似? --------------------编程问答-------------------- 楼主的文章显然是写给非技术人员的，这些文章往往是拿来给客户看的。ssl使用了非对称加密技术，也就是通常说的数字加密。要了解整个过程，必须了解非对称加密算法，散列算法，pki原理，等等。。。并不是很简单的。
建立ssl连接的简单过程是:客户端发一个握手消息，服务器发送自己的证书证明自己的身份（证书中包含了自己的公钥),客户端获得证书后，创建一个密钥（对乘密钥），并且封装到一个数字信封中，发送到服务器端,服务器是用自己的私钥解密数字信封，取出其中的密钥，这样双方都有了共同的密钥，可以使用这个密钥密密的通信。 --------------------编程问答-------------------- 在ssl建立的过程中，服务器还可以要求客户端提交证书，证明客户端的身份，这样就是双向认证了。这种认证很难破解。 --------------------编程问答-------------------- mark --------------------编程问答-------------------- mark --------------------编程问答-------------------- Mark
--------------------编程问答-------------------- mark
--------------------编程问答-------------------- mark --------------------编程问答-------------------- mark --------------------编程问答-------------------- mark --------------------编程问答-------------------- 也mark --------------------编程问答-------------------- 还是看E文原版文章好，国人自己写的文章都是瞎编乱凑的 --------------------编程问答-------------------- k，看了好几遍，就是看不懂
究竟是我自己笨，还是这个东西太深奥？或者表达不清楚？ --------------------编程问答-------------------- mark --------------------编程问答-------------------- 兄弟,转下贴呀~ www.pidc.cn --------------------编程问答-------------------- Remark :) --------------------编程问答-------------------- mark,too --------------------编程问答-------------------- mark --------------------编程问答-------------------- 加密解密方面的基本知识 --------------------编程问答-------------------- mark --------------------编程问答-------------------- 看看 rfc2246 ......
这个是 tls1.0 的,跟 ssl3.0 差不多,ssl2.0 过程也基本类似 ...
2年前做过 tls , 还是很简单的, 大概过程是酱紫的 ...
/* full handshake.
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
*/
ClientHello 包含随机数( client_rand )以及客户端所支持的加密/压缩算法列表
ServerHello 包含随机数( server_rand )以及选定的加密/压缩算法,以及session_id( 主要用于密钥恢复 ) ...
Certificate 包含服务器证书, ServerKeyExchange 包含服务器公钥,二者不会同时发送, 不发送Certificate包的时候安全性较低.
如果需要客户端验证, 则服务器将发送 CertificateRequest 请求客户端证书
最后跟随 ServerHelloDone 表示服务器响应结束
client随机生成 前主密文( pre_master_secret , tls1.0为48字节 ) 用服务器证书加密并包含在ClientKeyExchange包中被发送, 如果服务器请求客户端验证,则此时首先要发送客户端证书, 并对之前的协议数据签名, 签名包含在 CertificateVerify 中被发送, 通常在安全性要求很高的环境中(如网银等)才会要求双向验证. client发送 ChangeCipherSpec 表示密钥改变, 发送 Finished 表示客户端请求完成并包含对之前的协议数据的验证..
服务器用自己的私钥解密 前主密文 , 此时服务器和客户端用相同的数据( 包含 client_rand , server_rand , pre_master_secret ,其中只有 pre_master_secret 是加密的 ) 计算主密文( master_secret , tls1.0 也是48字节 ) , 最后双方用服务器在ServerHello
中选定算法计算加密参数( cipher_read , cipher_write , mac_read , mac_write , iv_read , iv_write ) ,服务器发送 ChangeCipherSpec 表示密钥改变, 发送 Finished 表示握手过程完成
密钥恢复就比较的简单, 如下图 ....
/* abbreviated handshake
Client Server
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
*/ --------------------编程问答-------------------- mark --------------------编程问答-------------------- 我也来说说我的看法阿
我们要知道，用非对称加密，就一定会牵扯到认证。前提是甲拥有乙的公钥
1。甲发给乙的消息是加了密的，别人看不懂，只有乙能看懂；但是不能做认证，也就是说，乙并不能完全确认：这个消息是否真的是甲发给他的，因为乙的公钥是公开的，谁都有，谁都能发加密的消息给他。
2。乙发给甲的消息，那么甲得到后只能做认证，确认这条消息是乙发给他的，不是其他人发给他的，但这条消息，不是加密，因为其他人也有乙的公钥，那么其他人也能看到这条消息。
上面两点很重要，我想楼主想问的是第二种认证吧。
认证就要知道 hash 算法，譬如MD5，它的大致思想是，根据认证的消息计算出一段固定长度的hash值，然后再用私钥对这个hash值签名，得出一段签名后的签名消息。然后将本来要发送的消息和这个签名消息一起送给对方，让对方验证，同样，对方也会对认证的消息计算出一段固定长度的hash值，然后用公钥来签名得到签名消息，最后它会比较自己的签名消息和对方发过来的签名消息，如果相同，那么就认为消息没有被更改过，否则，消息就被篡改了。 --------------------编程问答-------------------- lz看的那个资料我看着也有点晕
{信息段[甲，我是乙] } 乙的私钥 ——应该是使用散列函数生成[甲，我是乙]的消息摘要，然后使用乙的私钥对产生的信息摘要进行加密，此加密的消息摘要就是数字签名，然后将签名附加到原始消息上
为什么 "假冒者将发现不同的消息计算出相同的信息段值；"? —— 数字签名主要是要保证发送者的信息在发送过程中不会被篡改。甲在收到乙附加了数字签名的信息后使用消息头标明的散列算法处理此消息生成消息摘要，同时使用乙的公钥把附加在消息后的签名解密，然后比较两个摘要，如果相同则表明信息在传送过程中没有被修改。
散列算法是单向不可逆的（在有效的时间内几乎不可能），使用散列算法处理的信息修改其中一个字节产生的散列值都不会相同。 --------------------编程问答-------------------- lz看的资料是非对称密钥加密原理和数字签名原理，这些是数字证书的基础
SSL使用数字证书建立加密通道，我觉得要是说ssl的工作原理就不要把这些原理也写进去，直接说如何使用证书建立通道就行了，要是想说明数字证书就专门写一篇，现在这样都写在一起什么也没说清楚只能把大家都搞糊涂了。 --------------------编程问答-------------------- 当我们与一个网站建立https连接时，我们的浏览器与Web Server之间要经过一个握手的过程来完成身份鉴定与密钥交换，从而建立安全连接。具体过程如下：
1. 用户浏览器将其SSL版本号、加密设置参数、与session有关的数据以及其它一些必要信息发送到服务器。
2. 服务器将其SSL版本号、加密设置参数、与session有关的数据以及其它一些必要信息发送给浏览器，同时发给浏览器的还有服务器的证书。如果配置服务器的SSL需要验证用户身份，还要发出请求要求浏览器提供用户证书。
3. 客户端检查服务器证书，如果检查失败，提示不能建立SSL连接。如果成功，那么继续。
4. 客户端浏览器为本次会话生成pre-master secret，并将其用服务器公钥加密后发送给服务器。
5. 如果服务器要求鉴别客户身份，客户端还要再对另外一些数据签名后并将其与客户端证书一起发送给服务器。
6. 如果服务器要求鉴别客户身份，则检查签署客户证书的CA是否可信。如果不在信任列表中，结束本次会话。如果检查通过，服务器用自己的私钥解密收到的pre-master secret，并用它通过某些算法生成本次会话的master secret。
7. 客户端与服务器均使用此master secret生成本次会话的会话密钥(对称密钥)。在双方SSL握手结束后传递任何消息均使用此会话密钥。这样做的主要原因是对称加密比非对称加密的运算量低一个数量级以上，能够显著提高双方会话时的运算速度。
8. 客户端通知服务器此后发送的消息都使用这个会话密钥进行加密。并通知服务器客户端已经完成本次SSL握手。
9. 服务器通知客户端此后发送的消息都使用这个会话密钥进行加密。并通知客户端服务器已经完成本次SSL握手。
10. 本次握手过程结束，会话已经建立。双方使用同一个会话密钥分别对发送以及接受的信息进行加、解密。
--------------------编程问答-------------------- mark --------------------编程问答-------------------- mark --------------------编程问答--------------------
说的好，红色部分其实是对称密钥，你写错字了，
在SSL握手这个过程中充当对话密钥，是一次性的，这次回话结束之后就没用了。
补充：云计算 , 云安全
