yo2.cn
域名年龄: 21年9个月15天HTTP/1.1 404 Bad Request 服务器:nginx/0.7.67 访问时间:2013年10月18日 19:00:03 类型:text/html Transfer-Encoding: chunked 连接:keep-alive BlogCN-PHP-Engine: 12-11 缓存控制:不缓存,必须更新 其他指令:不缓存 Content-Encoding: gzip
Luke
First We Try , Then We Trust !
Skip to content
首页LabsLinksAbout
← Older posts
The Certificate Chains
Posted on 2009-12-23 by
概念解释:
标识名 (Distinguished Name, DN)
签名(Signing)
"三级证书"是指用户的SSL证书是在"受信任的根证书颁发机构"下的"中级证书颁发机构"下颁发的证书
"二级证书"只指用户的SSL证书是直接在 "受信任的根证书颁发机构"下颁发的证书。
请注意,这里的级别是指证书路径的级数(Level),要与证书的身份验证等级(Class)区分开 来,Class 3证书的身份认证过程要比Class 2证书的身份认证过程严格。
在实际使用中,为了提高网站的安全性,我们提供了https的访问的方式,https访问需要证书。
首先我上一个我们sso所使用的数字证书的图。
这是一个三级证书,我们将自己生成的CSR提交给签名商,他们用中级证书机构的私钥Private Key给我们的签名成证书。而他们的的证书又是通过Root CA颁发的(即Root CA通过它的私钥对中级机构提交的CSR进行了签名)。
签名的原理如下图。
下面是证书有效性验证的图。这就是证书链的概念所在。
Posted in 互联网
|
Tagged Certificate
|
Leave a comment
| 编辑
Public-key cryptography
Posted on 2009-12-23 by
[!TOC]
互联网的诞生之初就有信息安全问题的存在。
在信息技术高度发展的今天,信息安全更为重要,从对称加密,再到非对称加密,人们一直在为网络的安全做出斗争。
今天我这里谈的 主要是非对称加密。在传统的对称加密的情况下,密码很容易被泄露,这样信息的安全性就得不到保证。
但非对称加密的出现使得人们看到了希望。
在非对称加密中,有一对密钥,公钥和私钥。用公钥加密的信息只有用私钥才能解密,用私钥加密的信息只有用公钥才能解密。
其中公钥是公开出去的,可以给任何人。私钥是保密的只能自己知道。
所以我们可以通过非对称加密做一些对称加密无法做到的事情,
假设我们用公钥加密的过程为PubKeyEncrypt() 公钥解密为 PubKeyDecrypt()
私钥加密的过程为 PriKeyEncrypt()私钥解密的过程为PriKeyDecrypt()
1.身份认证
比如A和B进行交互,A发消息给B,B要怎么样才能判断接受的消息确实来自A呢? 可以这样
PriKeyEncrypt("hello", A's Private Key)然后发给B,然后B通过A的公钥来解密,如果正确的解密PubKeyDecrypt(msg,A's Public Key)得到hello,就说明信息确实来自A
但是这个时候问题出来了,B如何得到A的公钥呢?除非A和B认识,且A当面通过U盘或者别的方式把A的公钥交给B,然后B拿回去使用(在网络化的今天这很不现实),要不然在网络上直接传输的很有可能被拦截,然后被替换掉,那怎么办呢?
这个时候涉及一个公钥的发布的问题,目前的那些CA机构(Certificate Authority)所做的事情便是这个事(我心里老在想,CA机构给别人弄弄认证和证书一年就可以弄那么多钱,但是他的私钥的保密性的重要性,不言而喻啊)。
A将自己的公钥(通常是一个CSR--Certificate Signing Request文件,CSR文件包含了你的公钥,以及你的组织和域名的信息)和相关的营业证书或者能够证明法人身份的证件传真发给CA机构,CA机构(第三方的大家都可以信任的)会对A的身份进行全面的认证,确保A就是真正的A(这个时候需要A提供能够证明其身份的证明),同时明确各自在法律上的责任。如果认证成功之后,CA机构使用自己的私钥将A提交的公钥以及相关信息的哈希值进行加密,也叫签名。PriKeyEncrypt(Hash value,CA's Private Key) 这个时候得到的便是一个数字证书了。用户使用大家都信任的CA机构的Public Key将证书的签名解密可以得到相应的数字证书的哈希值然后比较看是否正确。
比如B得到A的证书(这个证书别人是无法伪造的,除非得到CA机构的私钥),B通过CA机构的公钥将这个证书解密,得到A的公钥,然后再来使用,这个时候就没有问题了。
2.数据的保密性和完整性
也许很多人看到数据的保密性会直接想到,通过非对称的方式对传输的数据进行加密不就可以保证了数据的保密性了么?
但是有一个成本的问题,非对称加密解密的成本比对称加密大的多,
这个时候我们需要对称加密和非对称加密相结合使用了。
比如B和A进行交互,B通过A的公钥将一个密码加密后传给A并协商好下面传输的信息都通过这个密码进行加密。
由于只有A的私钥才能解开这个将要使用的密码,所以密码的传输时绝对安全的。
数据的保密性得到保障之后,我们怎么才能保障数据在传输过程中,没有被恶意删减或修改呢,这个时候我们就需要保障数据的完整性。
保障数据的完整性,我们通常的做法就是通过哈希函数对需要传输的数据进行哈希求值(哈希值也称为输入数据的数字指纹Digital Fingerprint或消息摘要Message Digest等),一般情况下我们可以使用MD5或者SHA-1,一般情况下认为,只要原文有一点变化,哈希值就会变化。
算出的哈希值附在消息上一起发送给对方B,为了确保A在发给B的过程中,为了防止哈希值和原文同时被恶意修改,我们可以通过使用A的私钥对哈希值进行一次加密,这样只有得到A的私钥才能正确的修改这个哈希值。
3.不可否认性
这个比较好理解,比如A和B,A经过CA认证了,如果A通过自己的私钥加密发送消息给了B
那么A就无法否认了,因为只有使用A的私钥加密的信息才能被A的公钥进行解密。
Posted in 互联网
|
Tagged cryptography, public-key, security
|
Leave a comment
| 编辑
JDBC Test With Oracle
Posted on 2009-12-21 by
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;
public class OracleTest {
public static void main(String[] args) {
try {
String user = "user";
String password = "pass";
String driver = "oracle.jdbc.driver.OracleDriver";
String url = "jdbc: oracle:thin:@192.168.11.11:1521:dbname";
String sql = "SELECT sysdate FROM
© 2010 - 2020 网站综合信息查询 同IP网站查询 相关类似网站查询 网站备案查询网站地图 最新查询 最近更新 优秀网站 热门网站 全部网站 同IP查询 备案查询
2026-01-07 09:12, Process in 0.0069 second.