什么是SSL安全协议

第一篇：什么是SSL安全协议

什么是SSL安全协议

SSL安全协议最初是由Netscape Communication公司设计开发的，又叫“安全套接层(Secure Sockets Layer)协议”，主要用于提高应用程序之间数据的安全系数。SSL协议的整个概念可以被总结为：一个保证任何安装了安全套接字的客户和服务器间事务安全的协议，它涉及所有TC/IP应用程序。

SSL安全协议主要提供三方面的服务：

用户和服务器的合法性认证

认证用户和服务器的合法性，使得它们能够确信数据将被发送到正确的客户机和服务器上。客户机和服务器都是有各自的识别号，这些识别号由公开密钥进行编号，为了验证用户是否合法，安全套接层协议要求在握手交换数据时进行数字认证，以此来确保用户的合法性。

加密数据以隐藏被传送的数据

安全套接层协议所采用的加密技术既有对称密钥技术，也有公开密钥技术。在客户机与服务器进行数据交换之前，交换SSL初始握手信息，在SSL握手情息中采用了各种加密技术对其加密，以保证其机密性和数据的完整性，并且用数字证书进行鉴别，这样就可以防止非法用户进行破译。

保护数据的完整性

安全套接层协议采用Hash函数和机密共享的方法来提供信息的完整性服务，建立客户机与服务器之间的安全通道，使所有经过安全套接层协议处理的业务在传输过程中能全部完整准确无误地到达目的地。

安全套接层协议是一个保证计算机通信安全的协议，对通信对话过程进行安全保护，其实现过程主要经过如下几个阶段：

1.接通阶段：客户机通过网络向服务器打招呼，服务器回应;

2.密码交换阶段：客户机与服务器之间交换双方认可的密码，一般选用RSA密码算法，也有的选用Diffie-Hellmanf和Fortezza-KEA密码算法;

3.会谈密码阶段：客户机器与服务器间产生彼此交谈的会谈密码;

4.检验阶段：客户机检验服务器取得的密码;

5.客户认证阶段：服务器验证客户机的可信度;

6.结束阶段：客户机与服务器之间相互交换结束的信息。

当上述动作完成之后，两者间的资料传送就会加密，另外一方收到资料后，再将编码资料还原。即使盗窃者在网络上取得编码后的资料，如果没有原先编制的密码算法，也不能获得可读的有用资料。

发送时信息用对称密钥加密，对称密钥用非对称算法加密，再把两个包绑在一起传送过去。

接收的过程与发送正好相反，先打开有对称密钥的加密包，再用对称密钥解密。在电子商务交易过程中，由于有银行参与，按照SSL协议，客户的购买信息首先发往商家，商家再将信息转发银行，银行验证客户信息的合法性后，通知商家付款成功，商家再通知客户购买成功，并将商品寄送客户。

本文由：ev ssl证书 http://verisign.itrus.com.cn/ 整理

第二篇：浅析电子商务安全协议SSL与SET

浅析电子商务安全协议SSL与SET

一、引言

电子商务融计算机技术、通信技术、网络技术于一体，以Internet为基础平台，互动性、开放性、广泛性为其显著特点。由于其开放性与广泛性，必然面临各种安全风险，如信息泄露或被篡改、欺骗、抵赖等。所以，安全问题已成为发展可信赖电子商务环境的瓶颈。目前，众多的安全技术都是通过安全协议来实施的。因此，简洁、有效的安全协议对电子商务安全而言至关重要。现今，国际上主要通行的两种安全协议：安全套接层协议SSL和安全电子交易协议SET，二者均是成熟和实用的安全协议，但是由于它们的设计目的不同，所以在应用上有很大的差别。

二、两种电子商务安全协议介绍

（一）安全套接层协议SSL

SSL是网景(Netscape)公司提出的基于WEB应用的安全协议，其目的是在Internet基础上提供的一种保证机密性的安全协议。它能使客户端／服务器应用之间的通信不被攻击者窃听，并且始终对服务器进行认证，而且还可选择对客户端进行认证。

SSL协议是国际上最早应用于电子商务的一种网络安全协议，主要用于提高应用程序之间的数据安全。它同时使用对称加密算法和公钥加密算法，前者在速度上比后者要快很多，但是后者可以实现更好的安全认证。一个SSL传输过程首先需要握手：用公钥加密算法使服务器在客户端得到认证，以后就可以使用双方商议成功的对称密钥来更快速的加密、解密数据。

SSL协议要求建立在可靠的传输层协议(例如：TCP)之上。SSL协议的优势在于它是与应用层协议独立无关的。高层的应用层协议(例如：HTTP，FTP)能透明地建立于SSL协议之上。SSL协议在应用层协议通信之前就已经完成加密算法、通信密钥的协商以及服务器认证工作。应用层协议所传送的数据都会被加密，从而保证通信的机密性。对于电子商务应用来说，使用SSL可保证信息的真实性、完整性和保密性。SSL协议由SSL记录协议和SSL握手协议两部分组成。

1、SSL记录协议

在SSL协议中，所有的传输数据都被封装在记录中。所有的SSL通信，包括握手消息、安全空白记录和应用数据都使用SSL记录协议。记录协议允许服务器和客户端相互认证并协商加密算法和密钥，对所有发送和接收的数据进行分段、压缩、认证、加密和完整性服务。

2、SSL握手协议

SSL握手协议包括建立在记录协议之上的握手协议、警报协议、更改加密说明协议和应用数据协议等对会话和管理提供支持的子协议，其用于在通信双方之间建立安全传输通道。握手过程一般分为4个阶段：

(1)初始化逻辑连接，客户端先发出ClientHello消息，服务器返回一个ServerHello消息，这两个消息用来协商双方的安全能力，包括协议版本、对称加密算法、压缩算法等。

(2)服务器发送数字证书(包含了服务器的公钥等)和会话密钥。如果服务器要求认证客户端，则要发送CertificateRequest消息。最后服务器发送ServerHelloDone消息，表示hello阶段结束，服务器等待客户端的响应。

(3)如果服务器要求认证客户端，则客户端先发送Certificate消息，然后产生会话密钥，并用服务器的公钥加密，封装在ClientKeyExchange消息中，如果客户端发送了自己的数字证书，则再发送一个数字签名CertificateVerify来对数字证书进行校验。

(4)客户端发送一个ChangeCipherspec消息，通知服务器以后发送的消息将采用先前协商好的安全参数加密，最后再发送一个加密后的Finished消息。服务器在收到上述两个消息后，也发送自己的ChangeCipherspec消息和Finished消息。

至此，握手全部完成，双方就可以开始传输应用数据了。

3、SSL提供的功能及局限性

SSL使用加密的办法建立一个安全的传输通道,它可提供以下3种基本的安全服务功能：

(1)信息加密。客户端和服务器之间的所有的应用数据使用在SSL握手过程中建立的密钥和算法进行加密。这样就防止了某些用户通过使用IP packet sniffer等工具进行非法窃听或者破译。

(2)信息完整。SSL提供完整信息服务，以建立客户端与服务器之间的安全通道，使所有经过SSL协议处理的业务能全部准确无误地到达目的地。

(3)相互认证。客户端和服务器都有各自的识别号，这些识别号由公开密钥进行编号。为了认证用户是否合法，SSL协议要求在握手交换数据前进行数字认证，来确保用户的合法性。

SSL协议的局限性：首先，客户的信息先到商家，让商家阅读，这样，客户资料的安全性就得不到保证；其次，SSL只能保证资料信息传递的安全，而传递过程是否有人截取就无法保证了。所以，SSL并没有实现电子支付所要求的保密性、完整性，而且多方互相认证也是很困难的。此外，该协议最大的弱点是不能做数字签名，因此不支持不可否认性。另外，它不能对商家进行认证，不能防止网上欺诈行为。

（二）安全电子交易协议SET

安全电子交易(Secure Electronic Transaction．简称SET)协议是由Visa和Master Card公司在1996年底开发的，主要为在网上在线交易时保证使用信用卡进行支付时的安全而设立的一个开放的协议，它是面向网上交易，针对利用信用卡进行支付而设计的电子支付规范。SET提供了消费者、商家和银行之间的认证，确保交易的保密性、可靠性和不可否认性，从而保证在开放网络环境下使用信用卡进行在线购物的安全。目前，SET已得到IBM、Microsoft、VeriSign等著名公司的参与和支持，是国际上所公认的Internet电子商务的安全标准。

1、基于SET的交易流程

SET协议的购物系统由持卡人、商家、支付网关、收单银行、发卡银行和证书授权中心(CA)等六大部分组成，它们之间的关系如图1所示。

此外，基于SET协议的购物系统至少包括电子钱包软件、商家软件、支付网关软件和签发数字证书软件。目前，SET电子钱包主要是安装在客户端的交易软件，它是持卡人实现网上交易过程的主要工具。

SET协议在一般环境下的工作步骤如下：

(1)持卡人注册：持卡人为了使用信用卡，必须向支持SET的发卡银行申请开户，从而获得一个可用于Internet支付的信用卡帐号，同时向CA申请该信用卡的数字证书。此后，持卡人可以使用终端进行购物。

(2)商家注册：商家同样向CA申请用于电子商务支付的数字证书。此后，商家可以在网络上开设商城来销售货物。

(3)持卡人利用电子商务平台选定物品，并提交定单；

(4)商家接收定单，生成初始应答消息，数字签名后与商家数字证书、支付网关数字证书一起发送给持卡人；

(5)持卡人对应答消息进行处理，选择支付方式，确认定单，签发付款指令，将定单信息和支付信息进行双签名，对双签名后的信息和用支付网关公钥加密的支付信息签名后连同自己的数字证书发送给商家(商家看不到持卡人的帐号信息)；

(6)商家认证持卡人数字证书和双签名后，生成支付认可请求，并连同加密的支付信息转发给支付网关；

(7)支付网关通过金融专网到发卡银行认证持卡人的帐号信息，并生成支付认可消息，数字签名后发给商家；

(8)商家收到支付认可消息后，认证支付网关的数字签名，生成购买定单确认信息发送给持卡人。

至此交易过程结束。商家发送货物或提供服务并请求支付网关将购物款从发卡银行持卡人的帐号转账到收单银行商家帐号，支付网关通过金融专网完成转账后，生成取款应答消息发送给商家。

在以上的工作步骤当中，持卡人、商家和支付网关都通过CA来认证通信主体的身份，以确保通信的对方不是冒名顶替。

2、SET提供的功能

(1)所有信息在Internet上加密安全传输，保证数据不会被他人窃取。

(2)数字签名保证信息的完整性和不可否认性。

(3)订单信息和个人信用卡信息的隔离，使商家看不到客户的信用卡信息。

(4)参与交易各方的身份认证，保证各方身份不可假冒。

三、SSL与SET的比较

SET是一个多方面的消息报文协议，它定义了银行、商家、客户之间必须符合的报文规范。SSL只是简单地在客户端与服务器之间建立了一个安全传输通道，在涉及多方的电子交易中，只能提供交易中客户端与服务器间的认证，其并不具备商务性、服务性和集成性。SET报文能够在银行内部网络或其他网络传输，而SSL之上的支付系统只能与Web浏览器捆绑在一起。除此之外，它们还有以下区别：

1、认证机制方面，SET的安全需求较高，因此所有参与SET交易的成员都必须先申请数字证书来识别身份，而在SSL中只有商家服务器需要认证，客户端认证是可选的。

2、对客户而言，SET保证了商家的合法性，并且用户的信用卡号不会被窃取。SET替客户保守了更多的秘密使其在线购物更加轻松。在SSL协议中则缺少对商家的认证。

3、安全性上，SET的安全性较SSL高，主要原因是在整个交易中，包括客户到商家、商家到支付网关再到银行都受到严密的保护。而SSL的安全范围只限于客户到商家的信息交流。

四、结论

总的来讲，由于SSL协议的成本低、速度快、使用简单，对现有网络系统不需进行大的修改，因而其应用也相对较广泛。目前我国已有多家银行采用SSL协议，开展网上银行业务。SET协议比较复杂，它还要求在银行网络、商家服务器、客户端的PC上安装相应的软件，此外还要求必须向各方发放数字证书。这些都阻止了SET的广泛发展。但从安全性角度看，SSL协议不如SET协议安全，对于使用信用卡支付的系统来说，SET协议是最好的选择。

结合我国的具体情况，可以预见，电子商务安全措施在我国的发展趋势将是SET与SSL共存，优势互补。即在商家与银行之间采用SET协议，而与顾客连接时仍然使用SSL协议。这种方案既回避了在顾客端机器上安装软件。同时又可获得了SET提供的很多优点（作者单位：温州医学院计算机教研室）

第三篇：SSL实验报告

搭建证书服务器

步骤：

1、登陆Windows Server 2008服务器

2、打开【服务器管理器】

3、点击【添加角色】，之后点击【下一步】

4、找到【Active Directory证书服务】勾选此选项，之后点击【下一步】；

5、进入证书服务简介界面，点击【下一步】

6、将证书颁发机构、证书颁发机构WEB注册勾选上，然后点击【下一步】

7、勾选【独立】选项，点击【下一步】（由于不在域管理中创建，直接默认为：“独立”）

8、首次创建，勾选【根CA】，之后点击【下一步】

9、首次创建勾选【新建私钥】，之后点击【下一步】；

10、默认，继续点击【下一步】；

11、默认，继续点击【下一步】

12、默认，继续点击【下一步】

13、默认，继续点击【下一步】

14、点击【安装】

15、点击【关闭】，证书服务器安装完成

搭建WEB服务器端SSL证书应用

步骤:

1、打开IIS，WEB服务器，找到【服务器证书】并选中

2、点击【服务器证书】，找到【创建证书申请】项

3、单击【创建证书申请】，打开【创建证书申请】后，填写相关文本框，“通用名称”必需填写本机IP（192.168.72.128），单击【下一步】

4、默认，点击【下一步】

5、选择并填写需要生成文件的保存路径与文件名, 此文件后期将会被使用；（保存位置、文件名可以自行设定），之后点击【完成】，此配置完成，子界面会关闭

6、接下来，点击IE（浏览器），访问：http://192.168.72.128/certsrv/（本机ip）此时会出现证书服务页面；点击【申请证书】，进入下一界面点击【高级证书申请】，进入下一界面点击【创建并向此CA提交一个申请】，进入下一界面，此时会弹出一个提示窗口：“为了完成证书注册，必须将该CA的网站配置为使用HTTPS身份验证”；也就是必须将HTTP网站配置为HTTPS的网站，才能正常访问当前网页及功能

7、搭建HTTPS的网站：

方法：打开IE(浏览器)，找到工具栏，点击【工具栏】，找到它下面的【Internet选项】；、点击【Internet选项】->点击【安全】->点击【可信站点】；

10、点击【可信站点】，并输入之前的证书网站地址：http://192.168.72.128/certsrv，并将其【添加】到信任站点中；添加完后，点击【关闭】，关闭子界面

11、接下来，继续在【可信站点】位置点击【自定义级别】，此时会弹出一个【安全设置】子界面，在安全设置界面中拖动右别的滚动条，找到【对未标记为可安全执行脚本的ActiveX控件初始化并执行脚本】选项，将选为【启用】；之后点击所有【确定】操作，直到【Internet选项】子界面关闭为止

12、完成上面操作后，先将IE关闭，然后重新打开，输入：http://192.168.72.128/certsrv；页面出来后点击【申请证书】，【高级证书申请】，【使用base64编码的CMC或PKCS#10文件提交一个证书申请，或使用Base64编码的PKCS#7文件续订证书申请】

13、将之前保存的密钥文档文件找到并打开，将里面的文本信息复制并粘贴到“Base-64编码的证书申请”文本框中；确定文本内容无误后，点击【提交】

14、此时可以看到提交信息，申请已经提交给证书服务器，关闭当前IE

15、打开证书服务器处理用户刚才提交的证书申请； 回到Windows【桌面】->点击【开始】->点击【运行】，在运行位置输入：certsrv.msc，然后回车就会打开证书服务功能界面；

打开后，找到【挂起的申请】位置，可以看到之前提交的证书申请；

（图17）

18、点击鼠标右键会出现【所有任务】，点击【所有任务】->点击【颁发】将挂起的证书申请审批通过，此时挂起的证书会从当前界面消失，即代表已完成操作

19、点击【颁发的证书】，可以看到新老已审批通过的证书

20、重新打开IE，输入之前的网址：http://192.168.72.128/certsrv/； 打开页面后，可点击【查看挂起的证书申请的状态】；之后会进入“查看挂起的证书申请的状态”页面，点击【保存的申请证书】；

21、进入新页面后，勾选Base 64编码，然后点击【下载证书】,将已申请成功的证书保存到指定位置，后续待用；

22、打开IIS服务器，点击【服务器证书】->【完成证书申请】->选择刚保存的证书，然后在“好记名称”文本框中输入自定义的名称，完后点击【确定】

23、上述操作完后，可在“服务器证书”界面下看到证书

24、点击左边的【Default Web Site】菜单，然后找到【绑定】功能，点击【绑定】功能，会弹出【网站绑定】界面，默认会出现一个类型为http，端口为80的主机服务，然后点击【添加】，会弹出【添加网站绑定】界面，在此界面中选择“类型：https”、“SSL证书：JZT_TEST1”，然后点【确定】；点完确定后，会看到【网站绑定】子界面中有刚配的HTTPS服务，点击【关闭】，子界面消失

25、点击左菜单上的【CertSrv】证书服务网站，然后点击【SSL设置】

26、进入SSL设置页面，勾选上“要求SSL”即启用SSL功能，然后点击【应用】，保存设置

27、打开IE，再次输入：https://192.168.70.128

第四篇：电子商务安全协议SSL、SET的分析与研究演讲稿

第一张：标题 第二张：SSL 概念：安全套接层(Secure Sockets Layer，SSL)是一种传输层技术，可以实现兼容浏览器和服务器之间的安全通信。SSL协议是目前网上购物网站中常使用的一种安全协议。

1.SSL协议提供的服务主要有

(1)用户和服务器的合法性认证；

(2)加密数据以隐藏被传送的数据；(3)维护数据的完整性，2.SSL协议的工作流程

(1)接通阶段：客户通过网络向服务商发送连接信息，服务商回应；

(2)密码交换阶段：客户与服务器之间交换双方认可的密码，一般选用RSA密码算法，也有的选用Diffie-Hellmanf和Fortezza-KEA密码算法；

(3)会谈密码阶段：客户根据收到的服务器响应信息，产生一个主密钥，并用服务器的公开密钥加密后传给服务器；

(4)检验阶段：服务器恢复该主密钥，并返回给客户一个用主密钥认证的信息，以此让客户认证服务器。

(5)客户认证阶段：服务器通过数字签名验证客户的可信度；

(6)结束阶段，客户与服务商之间相互交换结束的信息。

3.SSL协议的缺点

（1）客户的信息先到商家，让商家阅读，这样，客户资料的安全性就得不到保证。

（2）SSL只能保证资料信息传递的安全，而传递过程是否有人截取就无法保证了。所以，SSL并没有实现电子支付所要求的保密性、完整性，而且多方互相认证也是很困难的。

4.电子商务中的应用。电子商务与网上银行交易不同，因为有商户参加，形成客户――商家――银行，两次点对点的SSL连接。客户，商家，银行，都必须具证书，两次点对点的双向认证。

第三张SET 概念: SET协议是由VISA和MasterCard两大信用卡公司于1997年5月联合推出的规范。SET主要是为了解决用户、商家和银行之间通过信用卡支付的交易而设计的，以保证支付信息的机密、支付过程的完整、商户及持卡人的合法身份、以及可操作性。SET中的核心技术主要有公开密钥加密、电子数字签名、电子信封、电子安全证书等。

1。SET支付系统的组成

SET支付系统主要由持卡人、商家、发卡行、收单行、支付网关、认证中心等六个部分组成。对应地，基于SET协议的网上购物系统至少包括电子钱包软件、商家软件、支付网关软件和签发证书软件。

2。SET安全协议主要提供三方面的服务

（1）保证客户交易信息的保密性和完整性：

（2）确保商家和客户交易行为的不可否认性：

（3）确保商家和客户的合法性：

3。SET协议的缺点

（1）只能建立两点之间的安全连线，所以顾客只能把付款信息先发送到商家，再由商家转发到银行，而且只能保证连接通道是安全的而没有其他保证。

（2）不能保证商家会私自保留或盗用他的付款信息。

4.SET的工作流程

①消费者在互联网选所要购买的物品，并在计算机上输入订货单

②通过电子商务服务器与有关商家联系，商家作出应答，告诉消费者所填订货单的货物单价、应付款数、交货方式等信息是否准确、是否有变化

③消费者选择付款方式，确认订单，签发付款指令，此时SET开始介入 ④在SET中，消费者必须对订单和付款指令进行数字签名，同时利用双重签名技术保证商家看不到消费者的足球新闻账号信息

⑤商家接受订单后，向消费者所在银行请求支付认可，信息通过支付网关到收单银行，再到电子货币发行公司确认，批准交易后，返回确认信息给商家

⑥商家发送订单确认信息给消费者，消费者端软件可记录交易日志，以备查询

⑦商家发送货物或提供服务，并通知收单银行将钱从消费者的账号转移到商店账号，或通知发卡银行请求支付。

第四张：SSL与SET协议的比较

（1）在认证要求方面，早期的SSL并没有提供商家身份认证机制，不能实现多方认证；而SET的安全要求较高，所有参与SET交易的成员都必须申请数字证书进行身份识别。

（2）在安全性方面，SET协议规范了整个商务活动的流程，从而最大限度地保证了商务性、服务性、协调性和集成性。而SSL只对持卡人与商店端的信息交换进行加密保护，可以看作是用于传输的那部分的技术规范。从电子商务特性来看，它并不具备商务性、服务性、协调性和集成性。因此SET的安全性比SSL高。

（3）在网络层协议位置方面，SSL是基于传输层的通用安全协议，而SET位于应用层，对网络上其他各层也有涉及。

（4）在应用领域方面，SSL主要是和Web应用一起工作，而SET是为信用卡交易提供安全，但如果电子商务应用是一个涉及多方交易的过程，则使用SET更安全、更通用些。

总结

由于SSL协议的成本低、速度快、使用简单，对现有网络系统不需进行大的修改，因而目前取得了广泛的应用。但随着电子商务规模的扩大，网络欺诈的风险性也在提高，在未来的电子商务中SET协议将会逐步占据主导地位。

第五篇：SSL(Secure Sockets Layer)协议与数字证书

SSL（Secure Sockets Layer）协议与数字证书 SSL的概述

由于 Web上有时要传输重要或敏感的数据，Netscape公司在推出 Web浏览器首版的同时，提出了安全通信协议 SSL（Secure Socket Layer）。

目的是在 Internet基础上提供一种基于会话加密和认证的安全协议。SSL协议已成为 Internet上保密通讯的工业标准。现行 Web浏览器普遍将 HTTP和 SSL相结合，从而实现安全通信。

SSL协议有以下三个特性 : 保密性。因为在握手协议定义了会话密钥后，所有的消息都被加密。

确认性。因为尽管会话的客户端认证是可选的，但是服务器端始终是被认证的。可靠性。因为传送的消息包括消息完整性检查（使用 MAC）。

SSL或 TSL工作在 TCP层与 HTTP,FTP,SMTP之间.2 SSL的体系结构

SSL协议分为两层协议。

一层是 SSL记录协议（SSL Record Protocol），它建立在可靠的传输协议（如 TCP）之上，为更高层提供基本的安全服务，如提供数据封装、压缩、加密 等基本功能的支持。

另一层是建立在 SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。它由三个协议组成：

• SSL握手协议（SSL Handshake Protocol）

• SSL修改密文规约协议（SSL Change Cipher Spec Protocol）• SSL告警协议（SSL Alert Protocol）

图：SSL 协议栈

SSL中协议中两个重要概念 ：

SSL连接（connection）：在 OSI分层模型的定义中，连接是提供一种合适类型服务的传输。而 SSL的连接是点对点的关系。连接是暂时的，每一个连接和一个会话关联。

SSL会话（session）：一个 SSL会话是在客户与服务器之间的一个关联。会话由握手协议创建。会话定义了一组可供多个连接共享的加密安全参数。会话用以避免为每一个连接提供新的安全参数所付出昂贵的代价。

① 会话状态 由下列参数定义：

 会话标识符 ：服务器选择的一个任意字节序列，用以标识一个活动的或可激活的会话状态。

   对方证书 ：一个 X.509.v3证书。可为空。

压缩方法 ：加密前进行数据压缩的算法。

密文规约 ：指明数据体加密的算法（无，或 DES等），以及用以计算 MAC散列算法（如 MD5或 SHA-1）。还包括其它参数，如散列长度，主密码（48位 C与 S之间共享的密钥），重新开始标志（指明该会话是否能用于产生一个新连接）。

② 连接状态 由下列参数定义：

   服务器和客户的随机数：服务器和客户为每一个连接所选择的字节序列。

服务器写 MAC密码：一个密钥，用来对服务器发送的数据进行 MAC操作。

客户写 MAC密码：一个密钥，用来对客户发送的数据进行 MAC操作。 服务器写密钥：用于服务器进行数据加密，客户进行数据解密的对称加密密钥；

 客户写密钥：用于客户进行数据加密，服务器 r进行数据解密的对称加密密钥；

 初始化向量：当数据加密采用 CBC方式时，每一个密钥保持一个 IV。该字段首先由 SSL握手协议初始化，以后保留每次最后的密文数据块作为下一个记录的 IV。

 序号：每一方为每一个连接的数据发送与接收维护单独的顺序号。当一方发送或接收一个修改的密文规约的报文时，序号置为 0，最大 264-1。SSL记录协议

在 SSL协议中，所有的传输数据都被封装在记录中。记录是由记录头和长度不为 0的记录数据组成的。所有的 SSL通信包括握手消息、安全空白记录和应用数据都使用 SSL记录层。SSL记录协议（SSL Record Protocol）包括了记录头和记录数据格式的规定。

1.SSL记录头格式

SSL的记录头可以是两个或三个字节长的编码。SSL记录头的包含的信息包括：记录头的长度、记录数据的长度、记录数据中是否有粘贴数据。2.SSL记录数据的格式

SSL的记录数据包含三个部分： MAC(Message Authentication Code)数据、实际数据和粘贴数据。

3.SSL记录协议操作

在 SSL的记录层完成对数据加密、解密和认证。操作过程如图所示：

SSL Record Protocol

All SSL protocol messages move in records of up to 32,767 bytes.Each message has a header of either 2 or 3 bytes.The headers include a security escape function, a flag to indicate the existence of padding, and the length of the message(and possibly the padding.)A two byte header has no padding, a three byte header includes some padding.The meaning of bits is as follows:

8

+----------------+-----------------+----------------+

|# S Length | Length | Padding length |

+----------------+-----------------+----------------+

# is the number of bytes in the header

0 indicates a 3 byte header, max length 32,767 bytes.1 indicates a 2 byte header, max length 16,383 bytes S

indicates the presence of a security escape, although none are

currently implemented.(Several suggestions for security

escapes are in the weaknesses section.)

There is no version information within the SSL record header, although it is available in the handshake.Within a record, there are three components: MAC-DATA, Actual-data, and Padding-data.MAC is the Message Authentication Code , Actual-data is the actual data being sent, and Padding-data is padding.The MAC-DATA is a hash of a key, the data, padding, and a sequence number.The hash is chosen based on the cipher-choice.The key used is the(sender)-write-key, which is the same key as the(receiver)-read-key.When cipher-choice is not defined, there is no mac-data or padding-data.Padding is used to ensure that the data is a multiple of the block size when a block cipher is used.Padding data is always discarded after the MAC has been calculated.Sequence numbers are unsigned 32 bit integers incremented with each message sent.Sequence numbers wrap to zero after 0xFFFFFFFF.Each dialog direction has its own sequence number.Failure to authenticate, decrypt, or otherwise get correct answers in a crytpographic operation result in I/O errors, and a close of connection.附： 主 密码的计算

主秘密(master secret)的生成，它是从预主秘密衍生出来的。当生成了一个预主秘密并且双方都知道它之后，就可以计算主秘密，用作共享秘密的主秘密是通过对许多先前的消息交接中的数据的杂凑计算构成的。

生成主密钥这些计算格式如下： Master_secret= MD5（pre-master-secret+SHA（A+pre-master-secre+ClientHello.random+ServerHello.random））+ MD5（pre-master-secret+SHA（BB+pre-master-secre+ClientHello.random+ ServerHello.random））+ MD5（pre-master-secret+SHA（BB+pre-master-secre+ClientHello.random+ ServerHello.random））修改密文规约协议

修改密文规约协议（SSL Change Cipher Spec Protocol）是简单的特定 SSL的协议。

目的：为表示密码策略的变化。该协议包括一个单一的消息，它由记录层按照密码规约中所指定的方式进行加密和压缩。在完成握手协议之前，客户端和服务器都要 发送这一消息，以便通知对方其后的记录将用刚刚协商的密码规范以及相关联的密钥来保护。所有意外的更改密码规范消息都将生成一个 “意外消息（unexpected_message）”警告。告警协议 警告协议将警告消息以及它们的严重程度传递给 SSL会话中的主体。就像由记录层处理的应用层数据一样，警告消息也用当前连接状态所指定的方式来压缩和加密。

当任何一方检测到一个错误时，检测的一方就向另一方发送一个消息。如果警告消息有一个致命的后果，则通信的双方应立即关闭连接。双方都需要忘记任何与该失败的连接相关联的会话标识符、密钥和秘密。对于所有的非致命错误，双方可以缓存信息以恢复该连接。握手协议

SSL握手协议负责建立当前会话状态的参数。双方协商一个协议版本，选择密码算法，互相认证（不是必需的），并且使用公钥加密技术通过一系列交换的消息在客户端和服务器之间生成共享密钥。

SSL握手协议动作包含四个阶段。握手协议的动作如图所示。

第一阶段 建立安全能力（1）Client Hello消息（2）Server Hello消息 第二阶段 服务器认证和密钥交换

（1）Server Certificate消息（2）Server Key Exchange消息（3）Certificate Request消息（4）Server Hello Done消息 第三阶段 客户认证和密钥交换（1）Client Certificate消息（2）Client Key Exchange消息（3）Certificate Verify消息 第四阶段 结束握手

（1）Change Cipher Spec 消息（2）Finished消息

（3）Change Cipher Spec 消息（4）Finished消息

握手交互流程：

C->S: 请求一个受保护的页面

S->C：返回附带公钥的证书

C：检查证书是否授信，不授信则提示客户端 C：产生一临时的对称密钥，并用服务端的公钥加密

C：用服务端的公钥加密需要请求的地址和附加的参数

C->S:将加密过的密钥和请求内容发送给服务端

S：首先用私钥解密获得两者交互的临时对称密钥

S->C：将请求的内容通过临时对称密钥加密返回给客户端

C->S：通过临时对称密钥开始交互

S->C：通过临时对称密钥加密并返回内容

数字证书

数字证书称为数字标识（Digital Certificate，Digital ID）。它提供了一种在 Internet 上身份验证的方式，是用来标志和证明网络通信双方身份的数字信息文件，与司机驾照或日常生活中的身份证相似。数字证书它是由一个由权威机构即 CA机构，又 称为证书授权（Certificate Authority）中心发行的，人们可以在交往中用它来识别对方的身份。在网上进行电子商务活动时，交易双方需要使用数字证书来表明自己的身份，并使用数字证书来进行有关交易操作。通俗地讲，数字证书就是个人或单位在 Internet上的身份证。

比较专业的数字证书定义是，数 字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公开密钥的文件。最简单的证书包含一个公开密钥、名称以及证书授权中心的数字签名。一般情况下证书中还包括密钥的有效时间，发证机关（证书授权中心）的名称，该证书的序列号等信息，证书的格式遵循相关国际标准。有了数字证书，我们在网络上就 可以畅通无阻。如图(数字证书授权中心)是一个数字证书在网络应用中的原理图。

图：数字证书授权中心

为什么需要数字证书呢？Internet网电子商务系统技术使在网上购物的顾客能够极其方便轻松地获得商家和企业的信息，但同时也增加了对某些敏感或有价值的数据被滥用的风险。买方和卖方都必须对于在因特网上进行的一切金融交易运作都是真实可靠的，并且要使顾客、商家和企业等交易各方都具有绝对的信心，因而网络电子商务系统必须保证具有十分可靠的安全保密技术，也就是说，必须保证网络安全的四大要素，即信息传输的保密性、数据交换的完整性、发送信息的不可否认性、交易者身份的确定性。

下面就是在证书中所包含的元素的列表。

  版本 ：它用来区别 X.509的各种连续的版本。默认值是 1988版本。

序列号 ：序列号是一个整数值，在发行的证书颁发机构中是唯一的。序列号与证书有明确联系，就像身份证号码和公民日常登记有明确联系一样。

 算法识别符 ：算法识别符识别证书颁发机构用来签署证书的算法。证书颁发机构使用它的私钥对每个证书进行签名。

  发行者或证书颁发机构 ：证书颁发机构是创建这个证书的机构。

有效期 ：提供证书有效的起止日期，类似于信用卡的期限。





主体 ：证书对他的身份进行验证。

公钥信息 ：为证书识别的主体提供公钥和算法识别符。 签名 ：证书签名覆盖了证书的所有其他字段。签名是其他字段的哈希代码，使用证书颁发机构的私钥进行加密，保证整个证书中信息的完整性。如果有人使用了证 书颁发机构的公钥来解密这个哈希代码，同时计算了证书的哈希代码，而两者并不相同，那么证书的某一部分就肯定被非法更改了。

图：证书内容

有了 数字证书以后，我们可以进行发送安全的电子邮件，实现网上邮件的加密和签名电子邮件，它还可以应用于公众网络上的商务活动和行政作业活动，应用范围涉及需要身份认证及数据安全的各个行业，如访问安全站点、网上招标投标、网上签约、网上订购、安全网上公文传送、网上办公、网上缴费、网上缴税、网上购物等网上 的安全电子事务处理和安全电子交易活动等。随着电子商务和电子政务的不断发展，数字证书的颁发机构 CA中心将作为一种基础设施为电子商务的发展提供可靠的保障。

Appendix2

SSL uses a scheme of https to reference documents available under HTTP with SSL.The https has a IANA reserved number of 443.SSL supports the RC2 & RC4 with either 128 bits or 40 bits of secret key information, as well as DES, 3 key 3DES, and IDEA.Details of all are covered in Schneier.A.The threats

As long as they confine themselves to playing by the rules established by Netscape, lookers can do little harm.There's little a looker with minimal resources can do against the deployed crypto systems used in SSL.Hacking one or more of the hosts or key certification authorities would seem to be a better option.Insiders, especially those around the top of the key certification hierarchy, have the potential to do quite a bit of harm by creating false signatures on keys.Few of these attacks will occur in a vengeful manner;they require time and foresight to enact, and are probably the domain of the malicious employee.(This assumes that employees who become vengeful do so at about the time they leave a firm.)

A criminal organization could, depending on its resources, possibly target an employee at a key certification organization.However, a more useful option might be to buy a cheap PC, and have it attempt brute force RC4 keys.It is estimated that a pentium based PC should be able to crack a 40 bit RC4 key in a month or several months using brute force.The manipulations used on the master key may increase the cost of tha attack, but probably not by orders of magnitude.If a PC costs $1500, then breaking 12 keys a year leads to a cost that could be as low as $125 per stolen card number.While this seems like a high price, the credit card numbers are acquired in a nearly risk free manner of sniffing an ethernet.In addition, that time will drop with the introduction of faster hardware.B.Protections

SSL explicitly examines a number of attacks that can be made against it, including brute force, clear text cryptanalysis, replay, and man in the middle.It does seem to protect well against those forms of attack.SSL is designed to protect at the network layer.This means it is not designed to, and does not, protect you from host breakins.To protect against host breakins, a Tripwire-like package should be integrated with the HTTPd.Tripwire uses cryptographically strong hashes to ensure documents have not been changed from some reference version.The database is usually stored on a physically write protected media like a floppy(Kim).C.Weaknesses

SSL, being a low level protocol, does little to protect you once your host is compromised.Also, once a key in a certificate is compromised, it can remain compromised, as there is no mechanism in place for consulting the root of a CA to confirm the key you are using has not been revoked.The keys however do include expiration dates.Climbing to the root CA is not a commonplace step, but a mechanism should be available to do so, for high value transactions.Out of band key repudiation is also desirable.Today, trusted key certifiers are compiled into the Netscape binary.The use of RC4 is troublesome, albeit understandable.RC4 is a newly published cipher, and although it was designed by the very competent Ron Rivest, it has not been subjected to the same kind of intense professional scrutiny that DES and IDEA have undergone.The decision to use RC4-40 is driven by the fact that it gets automatic export approval from the State Department.There are also a number of areas in the design of SSL as it stands that could become exploitable problems.None suggest an immediate means of attack, but are things which could be modified for possible added surety.Handshaking protocol: The challenge data, sent in the CLIENT-HELLO message, could in some types of handshakes, be sent later, encrypted.The data used in generating the session keys could include more data not sent in the clear.The means of generating the master key should be better specified, probably with reference to RFC-1750.Record protocol: Bad MAC-data should not terminate a connection, it should cause a repeat-request message.There are few attacks that will get anything from having the same data resent, and closing the connection on a bad message opens avenues for denial of service attacks.Sequence numbers should be randomly initialized.There are quite a few non-obvious attacks on sequence numbers(in IP, and NFS);it can't hurt to start with a non-predictable number.There should be a way for one or both sides to demand renegotiation of keys.Perhaps this could be implemented as a security escape.This is not needed for HTTP connection security, since the connections are very short lived, but if SSL is used, as the authors suggest, for telnet or FTP, the sessions could last substantially longer.