ssl协议说明

 

1.  下面这句话怎么解释？

为什么超过512位只允许用于签名而不允许用户密钥交换？难道超过512位用于密钥交换不是更加安全吗？

 

2.  Server Key Exchange Message 的作用

如果server没有证书，或者server的证书只用于签名（如DSS证书，或只用于签名的RSA证书），这时候server端就会生成一对临时的公私钥，用户密钥交换。

 

3. 客户端是如何确认sever端的身份的？

首先，通过证书的校验机制，验证证书的有效性；然后，使用证书公钥

 

4. 共享密钥的交换过程是怎样的？

 

5. 关于ssl的sessionid的概念？

如果sessionid标识的session在server端没有过期的话，就不需要再校验证书，协商密钥套件了。（如果server端的配置有问题的话，你会发现依然有证书校验的过程），该sessionid在客户端一般不会落地的，比如： 重启浏览器后该sessionid就消失了

 

6. ssl与tls的关系

ietf对ssl做了标准化，在ssl3.0的基础上定义了tls1.0 规范

 

7. curl -H “Host: login.sina.com.cn” -v “https://10.54.38.18/httpsdetector.php”

curl 不会使用-H指定的域名来和返回的证书做匹配的。也不会把ip作为server_name 写到ssl的扩展字段中，如果使用

curl “https://login.sina.com.cn/httpsdetector.php”

则会把 login.sina.com.cn 写到 ssl的server_name 的扩展字段中的

 

参考资料：

http://rrsongzi-gmail-com.iteye.com/blog/603015

 

http://wenku.baidu.com/view/1f64701a10a6f524ccbf8595.html

 

 

单个IP上配置多个HTTPS虚拟主机的实现

缘起

一度以为虚拟主机的配置是和http协议中的“Host”请求头有密切关系的，而ssl工作在http的下一层协议,先于http建立连接的，而在建立连接的时候是需要和“Host”相对应的证书的，再而且该证书在server端是配置在虚拟主机中的，所以，单个IP无法配置多个证书提供多个https的服务的，今天在阅读ssl的rfc时，一边也分析了ssl的握手过程，才发现host信息完全可以通过ssl的扩展字段告知server端该提供哪一份证书，于是，去百度google了一下，果然是可以这么做的。

相关概念

通配型ssl证书， 如： *.phpor.net ， 适用于 a.phpor.net,  b.phpor.net 等等

多域名ssl证书，即： 一个证书可以关联多个不相关的域名，为多个域名提供认证

 

参考资料

http://coolerfeng.blog.51cto.com/133059/91736/

http://zhumeng8337797.blog.163.com/blog/static/1007689142011023102443424/   （参考其中的mod_gnutls）

http://tools.ietf.org/html/rfc6101

http://www.ietf.org/rfc/rfc3546.txt   （参考其中的 server_name)

 

 

 

patch命令的用法

patch是个什么东西？有什么用呢？

从一个实际的例子说起吧，看一些linux上crond 的源码： http://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/vixie-cron-4.1-72.el5.src.rpm

打开该文件后，会发现里面有很多的patch文件，要想看到完整的cron的源文件，需要自己打这些patch，如果不了解patch命令还不太好办。

 

首先解压该文件，目录结构大概为：

/

1.patch

2.patch

…

vixie-cron-4.1.tar.gz     // 打patch之前的源文件

vixie-cron.spec

 

首先从vixie-cron.spec中grep出来要打的patch：

grep -i “^patch” vixie-cron.spec  |awk ‘{print $2}’ >~/phpor

然后解压vixie-cron-4.1.tar.gz

tar -zxf vixie-cron-4.1.tar.gz

cd vixie-cron-4.1

while read p; do patch -p1 <../$p; done <~/phpor

 

这样就ok了。

 

关于patch命令的参考资料：

http://blog.chinaunix.net/uid-9525959-id-2001542.html

 

patch练习：

1. 创建一个patch文件

diff -uN oldfile newfile>1.patch

2. 打patch

patch <1.patch

 

给目录打patch

1. diff -uNr olddir newdir>2.patch

2. 打patch

patch <2.patch

 

diff 参数说明：

-u ： 使用统一的输出格式 （默认的格式打patch不太好使）

-N： 对于目录比较来讲，新文件也打进去

-r： 对于目录来讲，递归处理子目录

 

 

 

 

CentOS源码在哪里

题记

作为一个和linux打交道的技术人员，需要了解linux、kernel、gnu、centos、redhat、RHEL等名词。

缘起

想看一下centos上的cron的源代码，不知道哪里找去；cron是centos发行版中自带的软件，你们http://centos.org 上应该有的吧，去了才发现里面都是二进制的代码包，根本没有源代码；最后是在http://redhat.com上找见的，为什么呢？这就是上面提到的需要了解的东西。

概念

linux通常指：kernel+gnu； kernel指的是内核，而gnu是一系列的开源的工具集；kernel+gnu依然是一个概念，不是一个可以使用的操作系统，而centos、redhat等等就是一个打包好的操作系统，就是我们通常所说的“发行版”；“发行版”是已编译好的操作系统，提供二进制的发布，不提供源代码，所以在centos.org上是找不到源代码的

centos5的源代码地址： http://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/

搜索方式： 在google中搜索：

vixie-cron-4.1-72.el5.src.rpm site:ftp.redhat.com

 

了解了这些之后，查看操作系统的源代码就方便多了，就不用到处去搜了

 

centos 安装文件： http://mirrors.sohu.com/centos/5/isos/i386/

网页上检测QQ已登录的实现机制

主要js文件：

http://imgcache.qq.com/ptlogin/ver/10013/js/xui.js?v=10007

建议将该文件格式化后分析，可以通过fiddler 自动响应的功能使用格式化的文件，然后在函数： onQloginSelect 上设置断点，然后跟踪下去就行了。

 

关键技术：

1. 浏览器插件，IE下使用 ActiveObjectX ，其它浏览器使用embed

2. 登录请求通过对域名的限制来实现

 

QQ登录插件文件：

C:\Program Files\Tencent\QQ\Bin\TXSSO\bin\npSSOAxCtrlForPTLogin.dll

 

分析的结果和下面文件中描述的一致，所以不再细说。曾经分析过，只是没有记录，都给忘了，这里记录一下。

 

相关参考资料： 搜索关键字：“embed application nptxsso”

http://1.lanz.sinaapp.com/?p=152

http://www.dewen.org/q/1027

http://www.udpwork.com/item/7598.html

 

学到的一些知识：

——————————————– 摘自上面参考资料

原来，QQ 使用了历史很悠久的 NPAPI（Netscape Plugin Application Programming Interface）接口。NPAPI 几乎支持所有主流浏览器，包括 FireFox、Chrome、Opera（IE 从 5.5 后停止支持 NPAPI，转而使用 ActiveX）。

打开 chrome://plugins/ 我们可以发现自动登录的有关插件，而在路径 C:\Program Files (x86)\Common Files\Tencent\TXSSO 下就可以找到关于 SSO 的相关动态链接库。

Tencent_SSO_plugin

np 插件一般命名都会加np前缀 如 QQ 的这个 npSSOAxCtrlForPTLogin.dll，只要按照标准的写法，放在浏览器会加载的地方，用的时候写个标签就可以在 js 里面调用了。于是跨浏览器（无视 IE）的插件开发变得相当可行。运行在 NPAPI 插件中的代码拥有当前用户的所有权限，不在沙箱中运行，所以它的扩展程序在被 Chrome 网上应用店接受前要求人工审核。

————————————————–

注意“插件”与“扩展”的区别，这里说的是“插件”； 上面提到的“人工审核”机制是怎么做到不审核就无法使用的呢？ 在浏览器上通过都需要该浏览器的厂商审核通过？