没有合适的资源?快使用搜索试试~ 我知道了~
通向架构师的道路(第十四天)Axis2 Web Service安全之rampart.docx
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 76 浏览量
2023-10-27
10:02:36
上传
评论
收藏 42KB DOCX 举报
温馨提示
试读
18页
通向架构师的道路(第十四天)Axis2 Web Service安全之rampart
资源推荐
资源详情
资源评论
一、加密保护我们的 web service 传输
在上一天的教程中,我们讲了一个简单的基于” security-constraint”的以指定用户名和密码来
保护一个 Web Service 以及如何用 https 对这个 web service 的通讯过程进行保护。虽然它
用 https 来进行保护了,但是我们抛开 https,这个 web service 之间传输的用户名,密码,
数据都是明文的。
在我之间教程中曾经提到过,有一种黑客工具叫作 sniffer,或者使用 MIM-ATTACK(中间
件拦截)的方式,也是可以把客户端的流拦截住并且发往黑客主机的,这样我们的用户名和
密码就可以被黑客所获取了。
因此,今天我们要讲述的就是如何在 web service 传输时,使得这个用户名和密码以及相关
数据也能被加密。
二、基本概念
我们先来看基本概念,这个基本概念将涉及到 PKI 的相关领域,请仔细看完这一章,要不
然后面你将云里雾里然后我劝你从头来过,我将参照麻省理工大学的教程-RSA 公司出版的
“计算机加密与解密原理”,用最实际的例子和最简化的语言把 PKI 中最重要的几个概念给大
家说清楚。
这次应该是我们第三次要求生成证书请求,证书,签名了,挺折腾的!!!
不折腾你们不行,我要把大家折腾的蛋疼,这次折腾过后就彻底明白了。
被折腾着,痛苦着并最后快活着,好了我废话又多了,下面开始。
2.1 加密解密的基本概念
我们的加密解密分两种:
1) 对称加密(Symmetric Cipher)
2) 非对称加密(Asymmetric Cipher)
2.1.1 对称加密
即采用一个密码(密钥)来对一串 String 进行解密,同样这个密码(密钥)也能对被加密
的密文进行解密,至始至终只有一个密码(密钥),因此它叫做对称加密。
2.1.2 非对称加密
这个是最重要的概念之一
我们知道,对称加密只有一把密钥(你可以把这个密钥看成一个密码)。而非对称加密呢?
它有 2 把密钥,
l 一把我们称为私钥即 privatekey,一把私钥可以对应着无数把公钥,公钥是可以“散播”的。
l 一把我们称为公钥即 publickey,一堆公钥只能对应着仅有的一把私钥,私钥是绝对不可
以“散播”的。
这两把密钥在产生时是被一起产生的,相当于同年同月生一样,即生成私钥时也伴随着生成
了公钥。
下面公式来了:
公钥加密,私钥解密
大家试想一下哈,我有两把钥匙,一把是用来专门锁门的(加密),一把是专门用来开门的
(解密)。那么我用来锁门的那把 key 掉了,被其它人捡到了,要不要紧?大不了别人可
以锁我家的门。
但是,如果我用来开门的这么 key 掉了?怎么办?被人捡到了人家就可以开我家的门进我
家了。
因此,公钥永远被用来加密,可以有多把被多人持有,而私钥永远用来解密且只能主人自己
拥有。
公钥加密,私钥解密!老老记住,这是永远的公式,也是真理!
2.1.3 数字签名
看了上面的“真理”即“公钥加密,私钥解密”后有人说了,我偏不信邪我就是要把它们倒过来,
好好好!我们一起来看倒过来是什么样的,即成了“私钥加密,公钥解密”了。但话不能这样
说,真理是不容否定的,但倒过来不是也行?
行,行是行,不过这句话就不能这样说了。
我们知道,公钥是可以多把的,私钥只有一把,因此:
1) 如果我们先把我们的明文用 MD5 或者 SHA1 这样的杂凑算法做一个杂凑,得到一堆杂
凑值我们称它为报文。
2) 然后呢我们拿着我们的私钥来对着这个得到的杂凑码不管它是 MD5 还是 SHA1,做一
个加密运算,就得到了一个“摘要”即 Digest。
3) 然后我们把这个摘要和我们的明文一起发送给接收方。
4) 接收方首先用与发送方一样的杂凑函数与接收到的原始明文中计算出这个杂凑计算,
得到杂凑值即报文。
5) 接着再用发送方的公用密钥来对这个报文附加的数字签名进行解密,这样,在接收方
手上就会有两样东西了。
l 接收方用发送方的公钥与所谓的原始明文运算得到的杂凑值或者称为报文也可称为摘要
即 digest。
l 接收方收到的由发送方发过来的摘要
6) 将这两要东西,就是两个摘要,它通常是如下的格式:
0a f5 b0 3f 38 6b 97 9c 08 62 9b 8b df d7 a0 c6 fe 00 12 08
把这两个摘要一比较,完全一致我们就可以说:
从接收方发送来的摘要是出自某某某之手!为什么?
举例来说:
因为我们的公钥和密钥在产生时是一对的,Andy 保留了私钥,他把公钥给了 Forest。
If
Forest 用这把公钥和明文得到的摘要如果==Andy 用私钥和明文做了杂凑后发来的摘要
Then
这条消息一定是 Andy 发过来的。
除非 Andy 把他的私钥交给了其它人并授权其它人代理他来做这个“私钥签证”
所以,我们得到另一条公式:
私钥签名,公钥认证
这也是一条真理,不能违背,这条真理也被称为“数字签名”,这边的“认证”也可以称为“被信
任”。
2.1.4 口令保护
我们的 private key,public key 如果一旦真的出现了 private key 被丢失的情况下怎么办?
不要紧,我们在 private key 上加一道锁:
这下成了最右边那个带锁的信封了,是不是,这个带锁的信封就是我们的钥匙袋。
你要拿到我的私钥就必须要先打开这个钥匙带,打开这个钥匙带你就必须再需要一把钥匙。
一般这把钥匙就是一个密码,我们称之为“口令”。
来看如下的一个 jks 的生成来理解吧:
keytool -genkey -alias shnlap93client -keyalg RSA -keysize 1024 -dname "CN=shnlap93,
OU=insurance, O=CTS, L=SH, S=SH, C=CN" -keypass bbbbbb -keystore
shnlap93client.jks -storepass bbbbbb
JKS 文件就是“公钥私钥证书”在一起的一种证书格式。
一般证书如 IE 中的证书都只带着公钥(public key),而 jsk 是同时带有公钥和私钥的证
书。
因此,如果你要得到这对密钥,你就必须要“解信封”,解开信封时你就要输入密码(口
令),这边的口令就是:keypass 即 bbbbbb 六个小写的 b。
2.2 回过头来看 https 与证书、公钥、私钥的关系
CA 证书签出一张服务器证书,在签出签书时 CA 使用自己的私钥,签完后怎么叫作这张被
签的证书生效呢?因为这张被签的证书中含有着 CA 证书中的“公钥”。
然后我们产生一个客户端的证书,该客户端的证书生成后我们把 CA 的公钥也“烧”到客户端
的证书里。
因此,我们有了下面这样的一个关系(见第十三天教程中的 3.3 小节-需要为我们的 Axis2
的调用客户端也建立起 https 中的互信)。
这边的客户端 jks 文件(带着 RootCA),就是带着 RootCA 的公钥,因为公钥是可以多把
的吗,因此 RootCA 可以把自己的公钥散播给其它人。
于是我们来套“私钥签名,公钥认证”这个公式就得到了:
1) 因为客户端的 jks 文件的公钥可以“认证”RootCA,即 RootCA 被客户端信任。
2) 因为服务端的 ks 文件也带着 RootCA 的公钥,可以“认证”RootCA,即 RootCA 可以被
服务端信任。
3) 因此,客户端可以信任服务端
2.3 使用 jks 文件来实现 Server-Client 间的“公钥加
密,私钥解密”
上面说了,客户端拥有 RootCA 的 public key,服务端也拥有 RootCA 的 public key,所以
客户端与服务端可以彼此间也建立起这条信任链。
但是,信任不代表它们可以实现“公钥加密,私钥解密”。
来看一个例子,这是今天的核心:
需求一、如果我们的客户端对一个 web service 进行加密,然后传到服务端进行解密。
对于需求一来说:
我们需要在客户端用服务端的公钥加密欲传给服务端的消息,然后在服务端得到客户端传过
来的加密消息后我们拿着服务端的私钥进行解密。
需求二、服务端将返回的 webservice 的内容先用客户端的公钥加密后传给客户端,客户端
用自己的私钥进行解密。
对于需求二来说:我们在服务端返回给客户端消息之间先用客户端的公钥对消息进行加密,
等消息传到客户端的时候,客户端再拿着客户端自己的私钥进行解密。
是不是就可以满足上述两个需求了?
于是,根据上面的描述我们来做一件事,即:
剩余17页未读,继续阅读
资源评论
小小哭包
- 粉丝: 1899
- 资源: 3860
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功