导航:首页 > 源码编译 > ssl弱加密算法

ssl弱加密算法

发布时间:2022-10-30 20:00:21

① HTTPS的前世今生和原理详解

HTTPS网络:

HTTP是明文传输的协议,数据很容易被窃听和篡改,并且攻击者很容易冒充客户端和服务端,HTTPS可以解决这两个的安全问题。HTTS仍是HTTP协议,只是在HTTP与TCP之间添加了用于加密数据的TSL/SSL协议。很多其它应用层的协议也采用在传输层之上添加TSL/SSL协议来保证安全,如FTPS、IMAPS。

加密和解密使用的是同一个密钥。加密和解密的双发都需要持有同一个密钥。常见对称加密算法:AES、DES、3DES。

加密和解密使用的是不同的密钥,加密时使用的密钥称为公钥匙,解密是使用的密钥称为私钥。使用公钥加密的密文只能用私钥解开。公钥可以发布出去使用,但私钥一定不能泄漏。常见的非对称加密算法:RSA、背包算法、ECC。

数字签名用于校验数据是否被篡改,即数据是否和原数据是否一致。
数字签名包含签名和验证两个运算。数字签名具有不可抵赖性,签名验证正确后就不能否认。
数字签名一般包含一个自己知道的私钥和一个公开的公钥,与传统的加密不同的是签名时使用私钥,验证签名是使用公钥。

1994年Netscape提出了SSL协议并制订了SSL协议的原始规范,即SSL1.0。但由于SSL1.0使用的是弱加密算法而受到密码学界的质疑,所以SSL1.0并没有公共发布。

SSL1.0之后Netscape对SLL协议规范进行了重大改近,并在1995年发布 SSL2.0协议 。虽然SSL2.0版本被认为是一个相当强大且健壮的协议,但仍存在一些易受攻击的漏洞,所以并没有得到广泛的使用。

由于SSL2.0的安全问题,Netscape联合哈佛的Paul Kocher等人重新设计了SSL协议,并在1996年发布,即SSL3.0版本,该版本较2.0版本有较大的差别。 SSL 3.0协议 获得了互联网广泛认可和支持。

随着互联网的飞速发展,网络安全越来越重要,业界非常迫切的需要一个标准的安全协议,于是IETE接手了SSL协议,并将其更名为 TSL(Transport Layer Security Protocol,安全传输层协议 ,并在1999年发布了TSL1.0版本。
不过TSL1.0于SSL3.0差别并不大(TLS 1.0 内部的协议版本号其实是3.1)。
虽然TSL是SSL的升级,但一些称呼上还存在混淆,所以大家通常将二者统称为SSL/TLS协议。

TSL1.1 于2006年发布,主要是修复了一些漏洞。

TSL1.2于2008年发布,1.2版本主要移除了一些老旧的加密套件,并引入了 AEAD 加密模式。1.2版本是目前应用最广泛的版本。

TSL1.3 于2018年发布。1.3版本在2014年提出,经4年的反复修改直到第28个草案才于2018年正式纳入标准。
1.3版本相较1.2版本有很大的改动,即增强了安全性也也大大提升了访问速度。主要有以下改动:

在公网通讯时想要保证通信信道的安全,目前来看只有将通信的数据进行加密后可防止窃听、冒充和篡改。

防止窃听:
数据加密后传输的就是加密后的密文,这些密文即使被窃听了但在没有解密的密钥的情况下是得不到真正的内容的。

防冒充和篡改:
通讯的数据加密后传输,在没有加密用的秘钥的情况下时无法构造出合法的数据包的,也就无法冒充或篡改数据。

将通信数据加密后传输可以解决很多的安全问题,但要实现通信的加密最为关键的点在于通信的双发用于加密的密钥怎么协商才能保证密钥不被泄漏和篡改那?密钥协商是HTTPS中最大的难点。

通信时使用对称加密,并且在客户端请求时直接将对称加密的密钥返回给客户端。
但在安全的信道建立起来之前任何传输仍是明文的,使用明文风发密钥毫无安全性可言,并且由对称加密使用同一个密钥,所以第三方在窃听到密钥后即可以窃听和篡改数据也可以冒充客户端和服务端。 所以直接分发对称加密的密钥显然行不通。

为方便说明这里只看客户端单向向服务端发送数据的情况,服务端向客户端发送数据与其类似。
通信时使用非对称加密,在客户端请求时将公钥放回给客户端。
但返回公钥时仍然是明文传输的,所以公钥还是很容易就会被泄漏,泄漏了公钥后,虽然第三方无在没有密钥的情况下是没法窃听数据或直接冒充服务端,但由于泄漏了公钥第三方还是可以冒充客户端或者进行‘中间人’攻击。
所以单纯使用非对称加密也是行不通的。

'中间人’攻击:

只要通信时使用的密钥不泄漏,那么在通信时完全没必要使用非对称加密,毕竟对称加密的效率更高。所以可以在通信正式开始前使用非对称加密来协商出通信时使用的对称加密的密钥,步骤如下:

虽然对称加密与非对称加密结合可以使我们或得两种的优点,但这样还是无法避免‘中间人’攻击。

DH密钥协商算法不会直接交互密钥,而是交互用于生产密钥的参数,DH算法基于当前‘无法’对大数进行质数分解来保证即使参数泄漏了,第三方也无法通过参数推导出密钥。
DH算法密钥协商步骤:

通过以上步骤客户端和服务端就协商出了密钥s,并且整个过程中没有传输过s。为了防止被破解a和b通常非常大,p 是一个至少 300 位的质数,g一般很小通常是3或者5.
但DH算法的缺点也很明显,DH无法防止冒充,还是会受到中间人攻击。

数字证书(digital certificate),又称公开密钥认证(Public key certificate)或身份证书(identity certificate),用来下发公钥匙和证明公钥拥有者的身份。

证书由第三机构颁发用来验证服务提供方的合法性,使用时服务提供方将证书给到客户端,客户端通过特定的机制验证书的合法性,从而信任提供证书的服务端和证书中的公钥。

数字证书以文件的形式存在,证书文件中包含了公钥信息、拥有者身份信息(主体)、以及数字证书认证机构(发行者)对数字证书自身的数字签名,证书的数字签名用来保证证书没有被篡改。

一般我们向CA申请证书时不用我们我们提供公钥和私钥,CA会给我们分配一个密钥对,并将公钥写到证书中,然后将证书和私钥给我们。

证书有统一的标准,其合法性(证书是否过期、数字签名是否有效、颁发的机构是否可信)通过一定的程序按标准来进行验证,如浏览器会保证HTTPS证书是否是合法的,linux下openSSL库提供了证书验证功能。

核对证书后若证书可信,就可以使用证书中的公钥对数据进行加密与证书的拥有者进行通信。

HTTPS的证书在扩展字段中包含了域名相关的信息,所以HTTPS的证书在申请的时候CA会严格的校验申请的机构或个人是否真的拥有这个域名。

数字证书认证机构(英语:Certificate Authority,缩写为CA)。证书标准是公开的任何人都可以去制作证书,但自己制作的证书是不受信任的,只有权威的CA机构颁发的证书才被信任。

权威的CA证书审核和部署流程严苛而繁杂,所以权威的根证书的有效期一般在几十年内。
也只有权威的CA的根证书会被各大操作系统支持,将其预制与操作系统内。

证书一般遵循X.509规范,主要包含以下内容:

CA生成的证书包含以上内容和一些扩展字段外,还包含CA使用自己的私钥对这些内容进行加密后的密文。在验证证书时使用CA的根证书对秘文进行验证,从而判断证书是否是合法的。

权威结构使用根证书来签发二级CA证书,二级CA证书可以给其它服务签发证书。但不是所有证书都可以继续签发新的证书,证书使用基础约束扩展来限制证书的签发,我们普通申请到证书基础约束扩展都是False的。查看根证书的基本约束可以看到证书颁发机构为‘是’。

根证书并不直接签发服务的证书,只要基于以下两点:

上一级证书对下一级证书进行签名,签名值包含在证书中,可以使用上一级证书中的公钥来验证下一级证书的签名值。根证书的签名是自己签的,并且验证签名的公钥包含在根证书中。

完整的证书连的关系应该有服务器放回,但有的并没有返回,对于没有放回完整证书连的证书,证书中的扩展字段CA 密钥标识符( Authority Key Identifier)记录了证书的上一个证书,通过该字段获取到上一级中间证书,再从中间证书的该字段中继续向上查找,直到根证书。
服务端最好可以返回证书连,这样可以避免浏览器自己去查找,提示握手速度。服务器返回的证书链并不包含根证书,根证书预至与操作系统内部。

在linux中openssl库会集成根证书。openssl的根证书的存放路径通过‘openssl version -a’查看。

校验证书时先根据证书链逐级校验证书的签名,签名校验的最关键的在根证书。根证书预至于操作系统中,CA要将自己的证书预至与各个系统中是非常困难的,所以预支与系统中的根证书是可信的。

回顾一下对于HTTPS的证书来说申请的时候CA会严苛的验证,保证这个域名是属于申请这个证书的机构的。这样攻击者或许可以伪造一个改域名的证书,但伪造的证书的根证书在系统中并不会存在,所以伪造的证书是不会被信任的。这样通过证书链的校验就可以有效的防止服务端被‘冒充’。

经过上面证书数字签名验证只是验证了证书确实是合法的证书,后还要验证证书的有效性,有效性验证主要包括以下字段:

验证合法的证书也可能由于种种原因被吊销,如证书的私钥泄漏了、证书错发了等,为了验证证书是否有效引入了证书吊销机制。

OSCP是证书提供方提供的证书验证接口,用户通过调用OSCP接口验证证书是否被吊销了。
但OCSP服务可能因为策略或服务故障导致无法访问,这时一般浏览器会选择信任证书,毕竟证书被吊销的情况只是极少数。也有部分CA将OCSP失败后的策略写到证书的扩展字段中,用用户根据扩展字段去做处理。
OSCP方式有自己明显的缺陷,为了验证证书而请求OSCP的同时也将自己在什么时候访问了什么服务也告诉了CA,CA利用我们的访问数据作恶咋办,还有OCSP的接口很慢的话不就拖慢了我们服务的相应数独。为了解决这两个问题各大CA厂商联手推出了CRL方案。

CRL方案是将被吊销的证书列表定期拉去到本机,一般是几天拉取一次。在校验证书时去本机列表中查找。
CA会在证书的扩展字段中写入CRL更新的地址:

CRL也有自己明显的确定,首先CRL是定期拉取的不能保证实时生效,然后CRL的列表一般很大可能达到数M。

CRLSet是chrome自建自用的解决方案。google觉得CRL更新太慢了,每个CA都有自己的CRL并且CRL内容也太多了。于是自己搞了一个CRLSet,将各大CA被吊销的高风险证书添加到CRLSet中,chrome在校验证书时可以去自己CRLSet中校验。
CRLSet只有各个CA吊销的证书的部分,大概包含所有吊销证书的2%。
CRLSet的更新相对快一些,最慢几个小时就会从各个CA中更新一次,CRLSet可以用在需要紧急吊销证书的情况下让吊销快速生效。

CRLSet提供了 https://github.com/agl/crlset-tools 工具来拉取和校验证书是否在CRLSet中。

可以在 chrome://components/ 中更新chrome的CRLSet

客户端向服务端发送hello请求,里面包含了客户端SSL/TSL的版本、支持的加密套件和一个随机数Random1

服务端收到客户端的hello后,根据客服端支持的加密套件和自己支持的加密套件选择出后面使用的加密和散列套件并返回给客户端,同时返回的还有服务端生产的一个随机数 Random2

服务端向客户端返回自己的证书,客户端收到证书后通过校验证书来信任服务端,并从证书中获取到证书中的公钥。

服务端在返回证书后会立即向客户端发送该请求。不过该请求不是必须的,只有选择的加密套件需要额外的参数是才会发送该请求交互参数。
如果密钥协议商算法是DH算法,那么DH的参数就在该请求中返回给客户端,DH算法有以下几种:DHE_DSS、DHE_RSA、ECDHE_ECDSAECDHE_RSA
dh算法会返回dh的参数p、g、dh的公钥和公钥的签名,公钥即g^b mod p,b为服务端的随机数

这里g就是0X03,p就是0X0017。

服务端在发送完上述信息后,就会立马发送Server Hello Done,来告知客户端服务端的相关信息已经发送完毕,就等客户端开始做密钥协商了。
客户端在收到该消息后就开始验证证书,协商密钥等工作。

在接受到服务器的Server Hello Done信息之后,客户端会计数出预备主密钥,并将其返回给服务端。

如果使用的是RSA/ECDSA算法,那么发送的就是预备主密钥。
如果使用的是DH算法,那么发送的就是通过之前的参数计数出来的公钥匙,即B( g^b mod p)服务端在收到B后通过 B ^ a mod p得到第三个随机数。而客户端已经通过s = A b mod 得到了s。

到了这里服务端和客户端已经得到了三个随机数,通过之前协商好的加密算法使用这个三个随机数就得到一个对称加密的密钥,后面通信时就使用该密钥。

该请求用于通知对方已经计数出通信用的密钥,接下来的通信都使用该密钥进行。服务端和客户端都会发出该请求,一般是服务端先发出。

在完成上述步骤以后,双发都会发送一个Finished请求给对方,Finished的数据是通过协商好的密钥加密的,以此来验证之前协商好的密钥、协议版本是否是有效的。

参考资料:

② 什么是SSL加密,什么是TLS加密

SSL加密的英文全称是Secure Socket Layer,翻译过来就是安全套接层。

它是在传输通信协议(TCP/IP)上实现的一种网络安全协议,广泛支持各种类型的网络,并同时提供三种网络基本安全服务,而且这三种服务都是使用公开密钥技术。

TLS加密的英文全称是Transport Layer Security,翻译过来就是安全传输层协议。

TLS是用于在两个通信应用程序之间,为通信提供保密性和数据完整性。这个协议一共有两层,分别是记录协议和握手协议。通过这个协议可以对网站、网络传真、电子邮件等数据传输进行加密、保密。

(2)ssl弱加密算法扩展阅读:

1、SSL

SSL协议优势

SSL协议的优势在于它是与应用层协议独立无关的。

高层的应用层协议(例如:HTTP、FTP、Telnet等等)能透明的建立于SSL协议之上。SSL协议在应用层协议通信之前就已经完成加密算法、通信密钥的协商以及服务器认证工作。在此之后应用层协议所传送的数据都会被加密,从而保证通信的私密性。

SSL体系结构

SSL被设计成使用TCP来提供一种可靠的端到端的安全服务,不是单个协议,而是二层协议。

低层是SSL记录层,用于封装不同的上层协议,另一层是被封装的协议,即SSL握手协议,它可以让服务器和客户机在传输应用数据之前,协商加密算法和加密密钥,客户机提出自己能够支持的全部加密算法,服务器选择最适合它的算法。

2、TLS

优势

TLS协议的优势是与高层的应用层协议(如HTTP、FTP、Telnet等)无耦合。

应用层协议能透明地运行在TLS协议之上,由TLS协议进行创建加密通道需要的协商和认证。应用层协议传送的数据在通过TLS协议时都会被加密,从而保证通信的私密性。

TLS协议是可选的,必须配置客户端和服务器才能使用。

主要有两种方式实现这一目标:一个是使用统一的TLS协议通信端口(例如:用于HTTPS的端口443);另一个是客户端请求服务器连接到TLS时使用特定的协议机制(例如:邮件、新闻协议和STARTTLS)。

算法

在客户端和服务器开始交换TLS所保护的加密信息之前,他们必须安全地交换或协定加密密钥和加密数据时要使用的密码。

参考资料来源:网络-SSL安全套接层

参考资料来源:网络-TLS安全传输层

③ 什么是SSL加密,什么是TLS加密

SSL加密是Netscape公司所提出的安全保密协议,在浏览器和Web服务器之间构造安全通道来进行数据传输,SSL运行在TCP/IP层之上、应用层之下,为应用程序提供加密数据通道,它采用了RC4、MD5以及RSA等加密算法,使用40 位的密钥,适用于商业信息的加密。

TLS是安全传输层协议。安全传输层协议(TLS)用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成: TLS 记录协议(TLS Record)和 TLS 握手协议(TLS Handshake)。较低的层为 TLS 记录协议,位于某个可靠的传输协议上面。

(3)ssl弱加密算法扩展阅读:

SSL加密并不保护数据中心本身,而是确保了SSL加密设备的数据中心安全,可以监控企业中来往于数据中心的最终用户流量。

从某个角度来看,数据中心管理员可以放心将加密装置放在某个地方,需要使用时再进行应用,数据中心应该会有更合理的方法来应对利用SSL的恶意攻击,需要找到SSL加密应用的最佳实践。

TLS协议是可选的,必须配置客户端和服务器才能使用。主要有两种方式实现这一目标:一个是使用统一的TLS协议通信端口(例如:用于HTTPS的端口443)。另一个是客户端请求服务器连接到TLS时使用特定的协议机制(例如:邮件、新闻协议和STARTTLS)。

一旦客户端和服务器都同意使用TLS协议,他们通过使用一个握手过程协商出一个有状态的连接以传输数据。通过握手,客户端和服务器协商各种参数用于创建安全连接。

参考资料来源:网络-SSL加密技术

参考资料来源:网络-TLS

④ 常见的几种SSL/TLS漏洞及攻击方式

SSL/TLS漏洞目前还是比较普遍的,首先关闭协议:SSL2、SSL3(比较老的SSL协议)配置完成ATS安全标准就可以避免以下的攻击了,最新的服务器环境都不会有一下问题,当然这种漏洞都是自己部署证书没有配置好导致的。

Export 加密算法

Export是一种老旧的弱加密算法,是被美国法律标示为可出口的加密算法,其限制对称加密最大强度位数为40位,限制密钥交换强度为最大512位。这是一个现今被强制丢弃的算法。

Downgrade(降级攻击)

降级攻击是一种对计算机系统或者通信协议的攻击,在降级攻击中,攻击者故意使系统放弃新式、安全性高的工作方式,反而使用为向下兼容而准备的老式、安全性差的工作方式,降级攻击常被用于中间人攻击,讲加密的通信协议安全性大幅削弱,得以进行原本不可能做到的攻击。 在现代的回退防御中,使用单独的信号套件来指示自愿降级行为,需要理解该信号并支持更高协议版本的服务器来终止协商,该套件是TLS_FALLBACK_SCSV(0x5600)

MITM(中间人攻击)

MITM(Man-in-the-MiddleAttack) ,是指攻击者与通讯的两端分别创建独立的联系,并交换其所有收到的数据,使通讯的两端认为他们正在通过一个私密的连接与对方直接对话,但事实上整个对话都被攻击者完全控制,在中间人攻击中,攻击者可以拦截通讯双方的通话并插入新的内容。一个中间人攻击能成功的前提条件是攻击者能够将自己伪装成每个参与会话的终端,并且不被其他终端识破。

BEAST(野兽攻击)

BEAST(CVE-2011-3389) BEAST是一种明文攻击,通过从SSL/TLS加密的会话中获取受害者的COOKIE值(通过进行一次会话劫持攻击),进而篡改一个加密算法的 CBC(密码块链)的模式以实现攻击目录,其主要针对TLS1.0和更早版本的协议中的对称加密算法CBC模式。

RC4 加密算法

由于早期的BEAST野兽攻击而采用的加密算法,RC4算法能减轻野兽攻击的危害,后来随着客户端版本升级,有了客户端缓解方案(Chrome 和 Firefox 提供了缓解方案),野兽攻击就不是什么大问题了。同样这是一个现今被强制丢弃的算法。

CRIME(罪恶攻击)

CRIME(CVE-2012-4929),全称Compression Ratio Info-leak Made Easy,这是一种因SSL压缩造成的安全隐患,通过它可窃取启用数据压缩特性的HTTPS或SPDY协议传输的私密Web Cookie。在成功读取身份验证Cookie后,攻击者可以实行会话劫持和发动进一步攻击。

SSL 压缩在下述版本是默认关闭的: nginx 1.1.6及更高/1.0.9及更高(如果使用了 OpenSSL 1.0.0及更高), nginx 1.3.2及更高/1.2.2及更高(如果使用较旧版本的 OpenSSL)。

如果你使用一个早期版本的 nginx 或 OpenSSL,而且你的发行版没有向后移植该选项,那么你需要重新编译没有一个 ZLIB 支持的 OpenSSL。这会禁止 OpenSSL 使用 DEFLATE 压缩方式。如果你禁用了这个,你仍然可以使用常规的 HTML DEFLATE 压缩。

Heartbleed(心血漏洞)

Heartbleed(CVE-2014-0160) 是一个于2014年4月公布的 OpenSSL 加密库的漏洞,它是一个被广泛使用的传输层安全(TLS)协议的实现。无论是服务器端还是客户端在 TLS 中使用了有缺陷的 OpenSSL,都可以被利用该缺陷。由于它是因 DTLS 心跳扩展(RFC 6520)中的输入验证不正确(缺少了边界检查)而导致的,所以该漏洞根据“心跳”而命名。这个漏洞是一种缓存区超读漏洞,它可以读取到本不应该读取的数据。如果使用带缺陷的Openssl版本,无论是服务器还是客户端,都可能因此受到攻击。

POODLE漏洞(卷毛狗攻击)

2014年10月14号由Google发现的POODLE漏洞,全称是Padding Oracle On Downloaded Legacy Encryption vulnerability,又被称为“贵宾犬攻击”(CVE-2014-3566),POODLE漏洞只对CBC模式的明文进行了身份验证,但是没有对填充字节进行完整性验证,攻击者窃取采用SSL3.0版加密通信过程中的内容,对填充字节修改并且利用预置填充来恢复加密内容,以达到攻击目的。

TLS POODLE(TLS卷毛狗攻击)

TLS POODLE(CVE-2014-8730) 该漏洞的原理和POODLE漏洞的原理一致,但不是SSL3协议。由于TLS填充是SSLv3的一个子集,因此可以重新使用针对TLS的POODLE攻击。TLS对于它的填充格式是非常严格的,但是一些TLS实现在解密之后不执行填充结构的检查。即使使用TLS也不会容易受到POODLE攻击的影响。

CCS

CCS(CVE-2014-0224) 全称openssl MITM CCS injection attack,Openssl 0.9.8za之前的版本、1.0.0m之前的以及1.0.1h之前的openssl没有适当的限制ChangeCipherSpec信息的处理,这允许中间人攻击者在通信之间使用0长度的主密钥。

FREAK

FREAK(CVE-2015-0204) 客户端会在一个全安全强度的RSA握手过程中接受使用弱安全强度的出口RSA密钥,其中关键在于客户端并没有允许协商任何出口级别的RSA密码套件。

Logjam

Logjam(CVE-2015-4000) 使用 Diffie-Hellman 密钥交换协议的 TLS 连接很容易受到攻击,尤其是DH密钥中的公钥强度小于1024bits。中间人攻击者可将有漏洞的 TLS 连接降级至使用 512 字节导出级加密。这种攻击会影响支持 DHE_EXPORT 密码的所有服务器。这个攻击可通过为两组弱 Diffie-Hellman 参数预先计算 512 字节质数完成,特别是 Apache 的 httpd 版本 2.1.5 到 2.4.7,以及 OpenSSL 的所有版本。

DROWN(溺水攻击/溺亡攻击)

2016年3月发现的针对TLS的新漏洞攻击——DROWN(Decrypting RSA with Obsolete and Weakened eNcryption,CVE-2016-0800),也即利用过时的、弱化的一种RSA加密算法来解密破解TLS协议中被该算法加密的会话密钥。 具体说来,DROWN漏洞可以利用过时的SSLv2协议来解密与之共享相同RSA私钥的TLS协议所保护的流量。 DROWN攻击依赖于SSLv2协议的设计缺陷以及知名的Bleichenbacher攻击。

通常检查以下两点服务器的配置

⑤ 什么是SSL加密技术

SSL是Netscape公司所提出的安全保密协议,在浏览器(如Internet Explorer、Netscape Navigator)和Web服务器(如Netscape的Netscape Enterprise Server、ColdFusion Server等等)之间构造安全通道来进行数据传输,SSL运行在TCP/IP层之上、应用层之下,为应用程序提供加密数据通道,它采用了RC4、MD5以及RSA等加密算法,使用40 位的密钥,适用于商业信息的加密。

SSL加密并不保护数据中心本身,而是确保了SSL加密设备的数据中心安全,可以监控企业中来往于数据中心的最终用户流量。从某个角度来看,数据中心管理员可以放心将加密装置放在某个地方,需要使用时再进行应用,数据中心应该会有更合理的方法来应对利用SSL的恶意攻击,需要找到SSL加密应用的最佳实践。

⑥ 什么是ssl

ssl加密的方法
关键词: ssl加密的方法
随着计算机网络技术的发展,方便快捷的互连网使人们渐渐习惯了从Web页上收发E-mail、购物和
交易,这时Web页面上需要传输重要或敏感的数据,例如用户的银行帐户、密码等,所以网络安全
就成为现代计算机网络应用急需解决的问题。

现行网上银行和电子商务等大型的网上交易系统普遍采用HTTP和SSL相结合的方式。服务器端采用
支持SSL的Web服务器,用户端采用支持SSL的浏览器实现安全通信。
SSL是Secure Socket Layer(安全套接层协议)的缩写,可以在Internet上提供秘密性传输。
Netscape公司在推出第一个Web浏览器的同时,提出了SSL协议标准,目前已有3.0版本。SSL采用公
开密钥技术。其目标是保证两个应用间通信的保密性和可靠性,可在服务器端和用户端同时实现支
持。目前,利用公开密钥技术的SSL协议,已成为Internet上保密通讯的工业标准。本文着重在
SSL协议和SSL程序设计两方面谈谈作者对SSL的理解。

SSL协议初步介绍
安全套接层协议能使用户/服务器应用之间的通信不被攻击者窃听,并且始终对服务器进行认证,
还可选择对用户进行认证。SSL协议要求建立在可靠的传输层协议(TCP)之上。SSL协议的优势在于
它是与应用层协议独立无关的,高层的应用层协议(例如:HTTP,FTP,TELNET等)能透明地建立于
SSL协议之上。SSL协议在应用层协议通信之前就已经完成加密算法、通信密钥的协商及服务器认证
工作。在此之后应用层协议所传送的数据都会被加密,从而保证通信的私密性。
通过以上叙述,SSL协议提供的安全信道有以下三个特性:
1.数据的保密性
信息加密就是把明码的输入文件用加密算法转换成加密的文件以实现数据的保密。加密的过程需要
用到密匙来加密数据然后再解密。没有了密钥,就无法解开加密的数据。数据加密之后,只有密匙
要用一个安全的方法传送。加密过的数据可以公开地传送。
2.数据的一致性
加密也能保证数据的一致性。例如:消息验证码(MAC),能够校验用户提供的加密信息,接收者可
以用MAC来校验加密数据,保证数据在传输过程中没有被篡改过。
3.安全验证
加密的另外一个用途是用来作为个人的标识,用户的密匙可以作为他的安全验证的标识。
SSL是利用公开密钥的加密技术(RSA)来作为用户端与服务器端在传送机密资料时的加密通讯协定。
目前,大部分的Web 服务器及浏览器都广泛支持SSL 技术。当浏览器试图连接一个具有SSL认证加
密的服务器时,就会唤醒一个SSL会话,浏览器检查认证,必须具备下面三个条件:
1)有一个权威机构发放证书,当然可以创建自我签订的证书(x509 结构)。
2)证书不能过期。
3)证书是属于它所连接的服务器的。
只有全部具备了这三个条件,浏览器才能成功完成认证。通过这三个条件,用户能确认其浏览器连接
到正确的服务器,而不是连接到一些想盗取用户密码等重要信息的虚假的服务器上。
在当今的电子商务中还有一项被广泛使用的安全协议是SET协议。SET(Secure Electronic Transaction,
安全电子交易)协议是由VISA和MasterCard两大信用卡公司于1997年5月联合推出的规范。SET能在电
子交易环节上提供更大的信任度、更完整的交易信息、更高的安全性和更少受欺诈的可能性。SET交
易分三个阶段进行:用户向商家购物并确定支付;商家与银行核实;银行向商家支付货款。每个阶段都
涉及到RSA对数据加密,以及RSA数字签名。使用SET协议,在一次交易中,要完成多次加密与解密操作,
故有很高的安全性,但SET协议比SSL协议复杂,商家和银行都需要改造系统以实现互操作。
在Linux 下,比较流行支持SSL认证的是OpenSSL服务器。OpenSSL项目是一个合作的项目,开发一个
健壮的、商业等级的、完整的开放源代码的工具包,用强大的加密算法来实现安全的Socket层
(Secure Sockets Layer,SSL v2/v3)和传输层的安全性(Transport Layer Security,TLS v1)。
这个项目是由全世界的志愿者管理和开发OpenSSL工具包和相关文档。
如何在Linux下配置OpenSSL服务器,首先从OpenSSL的主页(http://www.openssl.org/)上下载
openssl-version.tar.gz软件包来编译安装,与Apache服务器配合可以建立支持SSL的Web服务器,
并可以使用自我签订的证书做认证,关于如何编译、安装OpenSSL服务器,可以参考一下OpenSSL HOWTO
文档。

SSL 程序设计初步介绍
SSL 通讯模型为标准的C/S 结构,除了在 TCP 层之上进行传输之外,与一般的通讯没有什么明显的区
别。在这里,我们主要介绍如何使用OpenSSL进行安全通讯的程序设计。关于OpenSSL 的一些详细的信
息请参考OpenSSL的官方主页 http://www.openssl.org。
在使用OpenSSL前,必须先对OpenSSL 进行初始化,以下的三个函数任选其一:
SSL_library_init(void);
OpenSSL_add_ssl_algorithms();
SSLeay_add_ssl_algorithms();
事实上 后面的两个函数只是第一个函数的宏。
如果要使用OpenSSL的出错信息,使用SSL_load_error_strings (void)进行错误信息的初始化。以后
可以使用void ERR_print_errors_fp(FILE *fp) 打印SSL的错误信息。
一次SSL连接会话一般要先申请一个SSL 环境,基本的过程是:
1. SSL_METHOD* meth = TLSv1_client_method(); 创建本次会话连接所使用的协议,如果是客户端可
以使用
SSL_METHOD* TLSv1_client_method(void); TLSv1.0 协议
SSL_METHOD* SSLv2_client_method(void); SSLv2 协议
SSL_METHOD* SSLv3_client_method(void); SSLv3 协议
SSL_METHOD* SSLv23_client_method(void); SSLv2/v3 协议
服务器同样需要创建本次会话所使用的协议:
SSL_METHOD *TLSv1_server_method(void);
SSL_METHOD *SSLv2_server_method(void);
SSL_METHOD *SSLv3_server_method(void);
SSL_METHOD *SSLv23_server_method(void);
需要注意的是客户端和服务器需要使用相同的协议。
2.申请SSL会话的环境 CTX,使用不同的协议进行会话,其环境也是不同的。申请SSL会话环
境的OpenSSL函数是
SSLK_CTX* SSL_CTX_new (SSL_METHOD*); 参数就是前面我们申请的 SSL通讯方式。返回当前
的SSL 连接环境的指针。
然后根据自己的需要设置CTX的属性,典型的是设置SSL 握手阶段证书的验证方式和加载自己
的证书。
void SSL_CTX_set_verify (SSL_CTX* , int , int* (int, X509_STORE_CTX*) )
设置证书验证的方式。
第一个参数是当前的CTX 指针,第二个是验证方式,如果是要验证对方的话,就使用
SSL_VERIFY_PEER。不需要的话,使用SSL_VERIFY_NONE.一般情况下,客户端需要验证对方,而
服务器不需要。第三个参数是处理验证的回调函数,如果没有特殊的需要,使用空指针就可以了。
void SSL_CTX_load_verify_locations(SSL_CTX*, const char* , const char*);
加载证书;
第一个参数同上,参数二是证书文件的名称,参数三是证书文件的路径;
int SSL_CTX_use_certificate_file(SSL_CTX *ctx, const char *file, int type);
加载本地的证书;type 指明证书文件的结构类型;失败返回-1
int SSL_CTX_use_PrivateKey_file(SSL_CTX *ctx, const char *file, int type);
加载自己的私钥;type 参数指明私钥文件的结构类型;失败返回-1
加载了证书和文件之后,就可以验证私钥和证书是否相符:
BOOl SSL_CTX_check_private_key (SSL_CTX*);
3.既然SSL 使用TCP 协议,当然需要把SSL attach 到已经连接的套接字上了:
SSL* SSL_new (SSL_CTX*); 申请一个SSL 套节字;
int SSL_set_rfd (SSL*); 绑定只读套接字
int SSL_set_wfd (SSL*); 绑定只写套接字
int SSL_set_fd ( SSL*); 绑定读写套接字
绑定成功返回 1, 失败返回0;
4. 接下来就是SSL 握手的动作了
int SSL_connect (SSL*); 失败返回 -1
5. 握手成功之后,就可以进行通讯了,使用SSL_read 和SS_write 读写SSL 套接字代替传统的
read 、write
int SSL_read (SSL *ssl, char *buf, int num );
int SSL_write (SSL *ssl, char *buf, int num);
如果是服务器,则使用 SSL_accept 代替传统的 accept 调用
int SSL_accept(SSL *ssl);
6. 通讯结束,需要释放前面申请的 SSL资源
int SSL_shutdown(SSL *ssl); 关闭SSL套接字;
void SSL_free (ssl); 释放SSL套接字;
void SSL_CTX_free (ctx); 释放SSL环境;
OpenSSL 虽然已经发展到了0.9.96版本,但是它的文档还很少,甚至连最基本的man 函数手
册都没有完成。所以,本文紧紧是讲述了使用OpenSSL 进行程序设计的框架。更加详细的资
料可以参考OpenSSL 的文档或者 Apache mod_ssl 的文档。
通过以上的介绍,我想读者对SSL协议已经有了一定的了解,作者有机会将会继续给大家介绍
SSL协议的其他方面的内容。

SSL原理解密
本文出自:
http://noc.cstnet.net.cn/
范晓明

RSA公钥加密在计算机产业中被广泛使用在认证和加密。可以从RSA Data Security Inc.获得的RSA公钥加密许可证。公钥加密是使用一对非对称的密码加密或解密的方法。每一对密码由公钥和私钥组成。公钥被广泛发布。私钥是隐密的,不公开。用公钥加密的数据只能够被私钥解密。反过来,使用私钥加密的数据只能用公钥解密。这个非对称的特性使得公钥加密很有用。

使用公钥加密法认证

认证是一个身份认证的过程。在下列例子中包括甲和乙,公钥加密会非常轻松地校验身份。符号{数据} key意味着"数据"已经使用密码加密或解密。假如甲想校验乙的身份。乙有一对密码,一个是公开的,另一个是私有的。乙透露给甲他的公钥。甲产生一个随机信息发送给乙。甲——〉乙:random-message

乙使用他的私钥加密消息,返回甲加密后的消息。 乙——〉甲:{random-message}乙的私钥

甲收到这个消息然后使用乙的以前公开过的公钥解密。他比较解密后的消息与他原先发给乙的消息。如果它们完全一致,就会知道在与乙说话。任意一个中间人不会知道乙的私钥,也不能正确加密甲检查的随机消息。

除非你清楚知道你加密的消息。用私钥加密消息,然后发送给其他人不是一个好主意。因为加密值可能被用来对付你,需要注意的是:因为只有你才有私钥,所以只有你才能加密消息。所以,代替加密甲发来的原始消息,乙创建了一个信息段并且加密。信息段取自随机消息(random-message)并具有以下有用的特性:

1. 这个信息段难以还原。任何人即使伪装成乙,也不能从信息段中得到原始消息;

2. 假冒者将发现不同的消息计算出相同的信息段值;

3. 使用信息段,乙能够保护自己。他计算甲发出的随机信息段,并且加密结果,并发送加密信息段返回甲。甲能够计算出相同的信息段并且解密乙的消息认证乙。

这个技术仅仅描绘了数字签名。通过加密甲产生的随机消息,乙已经在甲产生的消息签名。因此我们的认证协议还需要一次加密。一些消息由乙产生:

甲——〉乙:你好,你是乙么?

乙——〉甲:甲,我是乙

{信息段[甲,我是乙] } 乙的私钥

当你使用这个协议,乙知道他发送给乙的消息,他不介意在上面签名。他先发送不加密的信息,"甲,我是乙。",然后发送信息段加密的消息版本。甲可以非常方便地校验乙就是乙,同时,乙还没有在他不想要的信息上签名。

提交公钥

那么,乙怎样以可信的方式提交他的公钥呢?看看认证协议如下所示:

甲——〉乙:你好

乙——〉甲:嗨,我是乙,乙的公钥

甲——〉乙:prove it

乙——〉甲:甲,我是乙 {信息段[甲,我是乙] } 乙的私钥

在这个协议下,任何人都能够成为"乙"。所有你所要的只是公钥和私钥。你发送给甲说你就是乙,这样你的公钥就代替了乙的密码。然后,你发送用你的私钥加密的消息,证明你的身份。甲却不能发觉你并不是乙。为了解决这个问题,标准组织已经发明了证书。一个证书有以下的内容:

* 证书的发行者姓名

* 发行证书的组织

* 标题的公钥

* 邮戳

证书使用发行者的私钥加密。每一个人都知道证书发行者的公钥(这样,每个证书的发行者拥有一个证书)。证书是一个把公钥与姓名绑定的协议。通过使用证书技术,每一个人都可以检查乙的证书,判断是否被假冒。假设乙控制好他的私钥,并且他确实是得到证书的乙,就万事大吉了。

这些是修订后的协议:

甲——〉乙:你好

乙——〉甲:嗨,我是乙,乙的校验

甲——〉乙:prove it

乙——〉甲:甲,我是乙 {信息段[甲, 我是乙] } 乙的私钥

现在当甲收到乙的第一个消息,他能检查证书,签名(如上所述,使用信息段和公钥解密),然后检查标题(乙的姓名),确定是乙。他就能相信公钥就是乙的公钥和要求乙证明自己的身份。乙通过上面的过程,制作一个信息段,用一个签名版本答复甲。甲可以校验乙的信息段通过使用从证书上得到的公钥并检查结果。

如果一个黑客,叫H

甲——〉H:你好

H——〉不能建立一个令甲相信的从乙的消息。

交换密码(secret)

一旦甲已经验证乙后,他可以发送给乙一个只有乙可以解密、阅读的消息:

甲——〉乙:{secret}乙的公钥

唯一找到密码的方法只有使用乙的私钥解码上述的信息。交换密码是另一个有效使用密码加密的方法。即使在甲和乙之间的通讯被侦听,只有乙才能得到密码。

使用密码作为另一个secret-key增强了网络的安全性,但是这次这是一个对称的加密算法(例如DES、RC4、IDE甲)。因为甲在发送给乙之前产生了密码,所以甲知道密码。乙知道密码因为乙有私钥,能够解密甲的信息。但他们都知道密码,他们都能够初始化一个对称密码算法,而且开始发送加密后的信息。这儿是修定后的协议:

甲——〉乙:你好

乙——〉甲:嗨,我是乙,乙的校验

甲——〉乙:prove it

乙——〉甲:甲,我是乙 {信息段[甲,我是乙] }乙的私钥

甲——〉乙:ok 乙,here is a secret {secret}乙的公钥

乙——〉甲:{some message}secret-key

黑客窃听

那么如果有一个恶意的黑客H在甲和乙中间,虽然不能发现甲和乙已经交换的密码,但能干扰他们的交谈。他可以放过大部分信息,选择破坏一定的信息(这是非常简单的,因为他知道甲和乙通话采用的协议)。

甲——〉H:你好

H——〉乙:你好

乙——〉H:嗨,我是乙,乙的校验

H——〉甲:嗨,我是乙,乙的校验

甲——〉H:prove it

H——〉乙:prove it

乙——〉H:甲,我是乙 {信息段[甲,我是乙] }乙的私钥

H——〉甲:甲,我是乙 {信息段[甲,我是乙] }乙的私钥

甲——〉H:ok 乙,here is a secret {secret} 乙的公钥

H——〉乙:ok 乙,here is a secret {secret} 乙的公钥

乙——〉H:{some message}secret-key

H——〉甲:Garble[{some message}secret-key ]

H忽略一些数据不修改,直到甲和乙交换密码。然后H干扰乙给甲的信息。在这一点上,甲相信乙,所以他可能相信已经被干扰的消息并且尽力解密。

需要注意的是,H不知道密码,他所能做的就是毁坏使用秘钥加密后的数据。基于协议,H可能不能产生一个有效的消息。但下一次呢?

为了阻止这种破坏,甲和乙在他们的协议中产生一个校验码消息(message authentication code)。一个校验码消息(MAC)是一部分由密码和一些传输消息产生的数据。信息段算法描述的上述特性正是它们抵御H的功能:

MAC= Digest[some message,secret ]

因为H不知道密码,他不能得出正确的值。即使H随机干扰消息,只要数据量大,他成功的机会微乎其微。例如,使用HD5(一个RSA发明的好的加密算法),甲和乙能够发送128位MAC值和他们的消息。H猜测正确的MAC的几率将近1/18,446,744,073,709,551,616约等于零。

这是又一次修改后的协议:

甲——〉乙:你好

乙——〉甲:嗨,我是乙,乙的校验

甲——〉乙:prove it

乙——〉甲:嗨,我是乙,乙的校验

甲,我是乙

{信息段[甲,我是乙] } 乙的私钥

ok 乙,here is a secret {secret} 乙的公钥

{some message,MAC}secret-key

现在H已经无技可施了。他干扰了得到的所有消息,但MAC计算机能够发现他。甲和乙能够发现伪造的MAC值并且停止交谈。H不再能与乙通讯。

OpenSSL FAQ

⑦ ssl用哪些加密算法,认证机制

SSL是一个安全协议,它提供使用 TCP/IP 的通信应用程序间的隐私与完整性。因特网的 超文本传输协议(HTTP)使用 SSL 来实现安全的通信。

在客户端与服务器间传输的数据是通过使用对称算法(如 DES 或 RC4)进行加密的。公用密钥算法(通常为 RSA)是用来获得加密密钥交换和数字签名的,此算法使用服务器的SSL数字证书中的公用密钥。

有了服务器的SSL数字证书,客户端也可以验证服务器的身份。SSL 协议的版本 1 和 2 只提供服务器认证。版本 3 添加了客户端认证,此认证同时需要客户端和服务器的数字证书。

详细介绍:网页链接

⑧ ssl证书的加密算法

作用与目的相同都是为了进行加密,更好的保护平台,SSL安全哈希算法,是数字签名算法标准,所以无论您在哪里注册无论多少价格的证书,其算法基本上都是相同的!

申请SSL证书为考虑到浏览器兼容性,保持更多的浏览器可以访问,通常采取加密算法:RSA 2048 bits,签名算法:SHA256WithRSA,该算法被公认使用,就是网络也使用该算法!

RSA加密算法:公钥用于对数据进行加密,私钥用于对数据进行解密。

RSA签名算法:在签名算法中,私钥用于对数据进行签名,公钥用于对签名进行验证。

加密算法分为两大类:1、对称加密算法 2、非对称加密算法。

由于计算能力的飞速发展,从安全性角度考虑,很多加密原来SHA1WithRSA签名算法的基础上,新增了支持SHA256WithRSA的签名算法。该算法在摘要算法上比SHA1WithRSA有更强的安全能力。目前SHA1WithRSA的签名算法会继续提供支持,但为了您的应用安全,强烈建议使用SHA256WithRSA的签名算法。

⑨ 目前SSL证书通常采用的哪种算法

为了考虑浏览器兼容性,通常使用以下算法:
加密算法:RSA
哈希签名算法:SHA256
加密位数:2048
最近ECC算法也比较普遍,主要有点是读取速度快了,但相反浏览器支持率降低了,首先IE7、IE6是肯定不支持的,甚至IE8也不支持。

⑩ SSL 证书的算法有哪些

根据密钥类型不同将现代密码技术分为两类:对称加密算法(秘密钥匙加密)和非对称加密算法(公开密钥加密)。

对称钥匙加密系统是加密和解密均采用同一把秘密钥匙,而且通信双方都必须获得这把钥匙,并保持钥匙的秘密。非对称密钥加密系统采用的加密钥匙(公钥)和解密钥匙(私钥)是不同的。

对称加密算法用来对敏感数据等信息进行加密,常用的算法包括:

DES(Data Encryption Standard):数据加密标准,速度较快,适用于加密大量数据的场合。

3DES(Triple DES):是基于DES,对一块数据用三个不同的密钥进行三次加密,强度更高。

AES(Advanced Encryption Standard):高级加密标准,是下一代的加密算法标准,速度快,安全级别高;


常见的非对称加密算法如下:

RSA:由 RSA 公司发明,是一个支持变长密钥的公共密钥算法,需要加密的文件块的长度也是可变的;


DSA(Digital Signature Algorithm):数字签名算法,是一种标准的 DSS(数字签名标准);


ECC(Elliptic Curves Cryptography):椭圆曲线密码编码学。

阅读全文

与ssl弱加密算法相关的资料

热点内容
旅游手机网站源码 浏览:311
android关联表 浏览:925
安卓导航无声音怎么维修 浏览:317
app怎么装视频 浏览:420
安卓系统下的软件怎么移到桌面 浏览:78
windows拷贝到linux 浏览:753
mdr软件解压和别人不一样 浏览:886
单片机串行通信有什么好处 浏览:321
游戏开发程序员书籍 浏览:844
pdf中图片修改 浏览:272
汇编编译后 浏览:477
php和java整合 浏览:833
js中执行php代码 浏览:445
国产单片机厂商 浏览:59
苹果手机怎么设置不更新app软件 浏览:287
转行当程序员如何 浏览:496
苹果id怎么验证app 浏览:866
查看手机命令 浏览:956
抖音反编译地址 浏览:228
如何加密软件oppoa5 浏览:235