适用范围：Dreamhost WebPanel

发现日期：2007-3-10

漏洞描述

在Dreamhost 注册的用户（包括免费帐户），均可通过修改自己的主email地址（primary e-mail contact address）为与系统中其他用户已设置的主email地址相同的方式，来获得对修改后的email地址原所属帐户的完全控制，被入侵用户正常的Dreamhost 服务不受影响，也不会受到任何警告和通知。

背景介绍

Dreamhost 的注册用户可以使用WebID 或者主email地址登录WebPanel ，管理帐户，WebID 由系统根据用户姓名自动生成，主email地址由用户在注册时提供，系统对两者都会进行唯一性检查，不允许重复。主email地址作为用户的联系方式，可以在profile 中随时进行更改，WebID 则不允许更改。

* NOTE-2: Each new Web ID MUST have a unique primary e-mail contact address! This is because you can log into the control panel either using your Web ID or your primary e-mail contact address. Also, the primary contact address is also the ONLY address that can be used for referrals! Additional address can also be added if you like, these can be duplicated across other Web IDs, but the primary contact address must be unique.

漏洞测试步骤 

1. 模拟用户A：在系统中注册免费帐户test1作为被入侵测试帐户，WebID为test1，主email 为test1@domain.com，密码：“111111”
2. 模拟用户B：在系统中注册免费帐户test2作为入侵测试帐户，WebID为test2，主email 为test2@domain.com，密码：“222222”
3. 用户B：登录test2帐户，编辑profile，将主email 地址修由test2@domain.com改为test1@domain.com，保存成功，退出登录
4. 用户B：检查test2@domain.com 收件箱，收到一封email地址变更通知
5. 用户A：检查test1@domain.com 收件箱，未收到任何来自Dreamhost的通知
6. 用户B：使用test1@domain.com 和密码“222222” 登录，登录成功，并且获得了与用户A 相同的访问控制
7. 用户B：使用WebID test1 和密码“222222” 登录，登录成功，获得对原有用户B 的资源访问。
8. 用户A：使用test1@domain.com 和密码“111111” 登录，一切正常

原因

在进行主email 变更时，系统未进行与注册步骤相同的email唯一性检查，致使作为用户唯一标识之一的主email 可能发生重复。Dreamhost 将会混淆两个原本完全不相关的帐户。结果是，用户A使用更改后的用户B的email 以及自己原有密码可以登录成功，并获得了用户B帐户的完全控制权，而那个不幸的用户B没有得到任何警告，他仍然可以使用自己的email 和密码正常登录自己的管理界面。

此时，Dreamhost WebID 并没有被搞混，用户A可以使用WebID 替代email，保持对自己原有帐户的访问。不过，很多用户大概不会留意WebID ， 有两个地方可以查知自己的WebID：

1. Dreamhost 发送的邮件主题，例如： [xxxxx 8729481] DreamHost Payment Receipt，xxxxx 就是WebID
2. 登录WebPanel，进入Edit Profile，界面显示："Welcome, xxxxx. Logout"，这里也能找到WebID

已将此问题反映给了Dreamhost 的Support Team，在问题得到修复之前，此篇日志不会被发布。

我会保持关注。

更新 2008-02-26

Dreamhost 已经修复此漏洞，下面是在profile 中修改主email的错误提示。

You cannot make sample@domain.com your primary address because another account already has it as its primary address!

恢复样式单，请点击这里，或者刷新本页。

最近几天看有关Firefox Extension 的开发，有很多知识链接，使用MindManager 做了这个思维导图，链接可以点击。

更新了链接，增加了浏览指引小图标

这样的图案很酷吗？glassgiant.com 提供免费的在线服务，让我们把任何图片转换成ASCII 形式的图案。在选择图片时要小心哦，太大的图片会花费很长时间进行生成的，一个2M的照片似乎花费了几分钟，几十k 的图片则很迅速。

Firefox 1.5 无法正常访问这个服务，还好，新装了IE Tab 插件，一键在Firefox 与IE 之间切换很方便。

这里还有一些现成的ASCII  图案 ，给手懒的人看。

我使用awstats 统计日志数据，在config 文件中，我设定如下参数：

LogFile="/home/username/logs/aiview.com/http/access.log"

我在crontab 中设定每天在整点每间隔4个小时运行一次统计更新。

00 0-23/4 * * * ~/jobs/updawt.sh  

我的空间在Dreamhost ，日志生成情况如下，包含当天，一共有最近6天的日志文件，当天的命名为 access.log，前五天加日期后缀，最早的4天压缩存储，第五天不压缩。同时为第五天的日志建立了一个名为access.log.0 的符号连接。

-rw-r--r--  1 root       root      1830112 Apr 16 22:03 access.log
lrwxrwxrwx  1 root       root           21 Apr 16 01:03 access.log.0 -> access.log.2007-04-15
-rw-r--r--  1 xxx        xxx       255078 Apr 11 00:50 access.log.2007-04-10.gz
-rw-r--r--  1 xxx        xxx       222179 Apr 12 00:58 access.log.2007-04-11.gz
-rw-r--r--  1 xxx        xxx       214981 Apr 13 00:07 access.log.2007-04-12.gz
-rw-r--r--  1 xxx        xxx       150369 Apr 14 00:13 access.log.2007-04-13.gz
-rw-r--r--  1 root       root      1096740 Apr 16 01:03 access.log.2007-04-15 

我在配置文件中指定的文件名是access.log ，从前，我一直以为awstats 会自动合并access.log.[0-9]，也包括这里的access.log.0 ，但刚刚发现，awstats 并不做这件事情，除非详细指定。

结果就是，我会丢失从日志文件发生轮换那一刻起，至最后一次统计更新之间的那部分日志的统计数据，因为它们没有获得被统计的机会，就被重命名为access.log.0 。而依据我的设置，access.log.0 并不在统计范围。

这里还有一些细节，统计数据是否会丢，以及会丢掉多少，还取决于日志轮换的具体时间（并不总是发生在零点），以及我的job 执行间隔与执行时间。无论如何，更改配置文件，使其不依赖于这些不确定因素是好的方法。

我修改了我的统计配置文件如下：

#LogFile="/home/username/logs/aiview.com/http/access.log"
LogFile="./tools/logresolvemerge.pl /home/username/logs/aiview.com/http/access.log /home/username/logs/aiview.com/http/access.log.0 |" 

logresolvemerge.pl 随awstats 程序包提供，你需要指定适用你的正确路径。 

awstats 文档中提供了一个方法 ，需要清空过去所有的统计数据，并依次重新更新所有的历史日志；另外还包含了一个tips，不必清空所有过去的统计数据，就可以把过去遗漏的某天数据加入统计，但依然要求清空一整个月的统计数据。

这些历史统计数据保存在config 文件中DirData 参数所定义的目录中，并且是按月保存的。

awstats.aiview.com.conf ：

DirData="./xyz"

目录包含文件： 

awstats012007.aiview.com.txt
awstats022007.aiview.com.txt
awstats032007.aiview.com.txt
awstats042007.aiview.com.txt

前几日，Dreamhost 报告文件服务器发生了一些故障，之后就发现我的http 日志停止了更新，在其恢复服务后，12、13日的日志被重新刷新，但14日全天以及15日部分日志丢失。

今天是16日，在日志丢失期间，已经通过crontab 自动更新过多次统计数据，只是这几天统计数据都为零。要想补上12、13、15日的统计数据，只有清除4月份的统计数据文件：awstats042007.aiview.com.txt 文件，并从4月1日开始依次更新所有统计数据。但Dreamhost 只保存最近6天的http 日志，这个办法行不通。

经查看awstats  历史统计数据文件，找到解决方法，算是另外一个tips 。

以下代码片段来自4月份统计数据文件：awstats042007.aiview.com.txt 。LastTime 参数保存了统计的http 日志条目最晚的时间（区别于运行update 的时间），我们可以通过把其他几个时间参数修改为此时间，并且重置一些条目参数来达到目的。

LastLine 20070416000000 4386 898321 47205111575
FirstTime 20070401002121
LastTime 20070412035620
LastUpdate 20070416000004 2542 0 0 0 2542

 下面是修改后的条目：（修改前请先备份旧文件！）

LastLine 20070412035620 0 0 0
FirstTime 20070401002121
LastTime 20070412035620
LastUpdate 20070412035620 0 0 0 0 0

接着修改config 文件，注释掉原来的日志路径，指向到旧的日志压缩文件。

#LogFile="/home/username/logs/aiview.com/http/access.log"
LogFile="gzip -d </home/username/logs/aiview.com/http/access.log.2007-04-12.gz |" 

然后运行命令更新统计数据。（注意：如果设置有crontab，操作前最好先disable 任务，免得引起不期望的结果）

$ cd ~/aiview.com/cgi-bin/awstats/
$ ./awstats.pl -config=aiview.com -update 

这时刷新统计页面，已经可以看到13日的统计数据，依次在config 文件中把日志更换为13、15日的文件，并逐次运行更新，即可把所缺日志依次补回。

这种方法虽然不要求具有当天至月初的所有访问日志文件，但要求具有所补日期至当天或者至当月末的所有日志文件。 

看来，写个job 定期备份日志还是有必要的。 

下面是一个例子，红色部分代表遇到了一个脚本错误。

点开后，Firebug 指示出了错误文件与相关代码行。

 再继续查看，就直接定位到了相关上下文，这里我们可以看到，是在line 22 多了一个额外的注释标记 "*/"，导致此错误。

修复后，显示正常状态。

如果错误不太容易找到，还可以设置断点进行调试，直接在行号部分点击即可设置断点，然后刷新一次网页重新执行脚本，执行到断点处会自动停下，可以像通常调试工具一样选择执行进度，观察并设置变量。

Firebug 是完全免费的，要了解更多的功能，请参考考官方网站 。 

<link rel="stylesheet" type="text/css" href="http://www.aiview.com/css/screen.css" media="screen" />
<link rel="stylesheet" type="text/css" href="http://www.aiview.com/css/screen.css" media="projection" />

对待这样的CSS定义，Firefox 会把screen.css 完整下载两次，而IE 仅仅会有一次访问。

123.112.2.228 - - [12/Apr/2007:09:34:10 -0700] "GET /css/screen.css HTTP/1.1" 200 5327 "http://www.aiview.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
123.112.2.228 - - [12/Apr/2007:09:39:11 -0700] "GET /css/screen.css HTTP/1.1" 200 5327 "http://www.aiview.com/" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11"
123.112.2.228 - - [12/Apr/2007:09:39:12 -0700] "GET /css/screen.css HTTP/1.1" 200 5327 "http://www.aiview.com/" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11"

但是对于另外一项，它们却有不同的表现。

<link rel="alternate stylesheet" type="text/css" href="http://www.aiview.com/css/print.css" media="screen" title="PrintPreview"/>
<link rel="stylesheet" type="text/css" href="http://www.aiview.com/css/print.css" media="print" />

Firefox 针对print.css 访问了一次，而IE 则有两次，第二次是http 304 ，也属于正常。

123.112.2.228 - - [12/Apr/2007:09:34:10 -0700] "GET /css/print.css HTTP/1.1" 200 1486 "http://www.aiview.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
123.112.2.228 - - [12/Apr/2007:09:34:11 -0700] "GET /css/print.css HTTP/1.1" 304 256 "http://www.aiview.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
123.112.2.228 - - [12/Apr/2007:09:39:12 -0700] "GET /css/print.css HTTP/1.1" 200 1486 "http://www.aiview.com/" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11" 

再来看另外一个例子，screen.css 与screen-clearstyle.css 均引用了base.css 和extend.css 。

<link rel="stylesheet" type="text/css" href="http://www.aiview.com/css/screen.css" media="screen" title="GetStyleBack" />
<link rel="stylesheet" type="text/css" href="http://www.aiview.com/css/screen-clearstyle.css" media="screen" title="ClearStyle" />

@import "base.css";
@import "extend.css";

对于多个CSS 文件引用的同一个CSS，Firefox 不会再去检查文件修改日期，而IE 照例进行了多次访问，虽然后续仅访问了header，如果引用比较复杂的话，还是有一些可观流量的。

123.112.2.228 - - [12/Apr/2007:09:34:10 -0700] "GET /css/screen.css HTTP/1.1" 200 5327 "http://www.aiview.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
123.112.2.228 - - [12/Apr/2007:09:34:10 -0700] "GET /css/base.css HTTP/1.1" 200 1484 "http://www.aiview.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
123.112.2.228 - - [12/Apr/2007:09:34:11 -0700] "GET /css/base.css HTTP/1.1" 304 256 "http://www.aiview.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
123.112.2.228 - - [12/Apr/2007:09:34:11 -0700] "GET /css/extend.css HTTP/1.1" 200 1964 "http://www.aiview.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
123.112.2.228 - - [12/Apr/2007:09:34:11 -0700] "GET /css/extend.css HTTP/1.1" 304 256 "http://www.aiview.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
123.112.2.228 - - [12/Apr/2007:09:39:11 -0700] "GET /css/screen.css HTTP/1.1" 200 5327 "http://www.aiview.com/" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11"
123.112.2.228 - - [12/Apr/2007:09:39:11 -0700] "GET /css/base.css HTTP/1.1" 200 1484 "http://www.aiview.com/css/screen.css" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11"
123.112.2.228 - - [12/Apr/2007:09:39:11 -0700] "GET /css/extend.css HTTP/1.1" 200 1964 "http://www.aiview.com/css/screen.css" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11"

通过这次测试，还学习了一点额外的东西，对于浏览器来说，F5 与CTRL+F5 有一些区别，虽然都是刷新，但F5 仅仅会重新获取相比cache 有所更新的文件，CTRL+F5 则强制性重新获取所有文件。另外提一点，在Firefox 中，F5 与工具栏中的刷新按钮，或者是菜单中的刷新项(CTRL+R)，效果都一样，IE 也是如此。

顺便把CSS 切换功能 给取消了，还是保持简单点好。因此上面的部分代码，在页面源文件中已经找不到了，下面是个完整的参考：

<link rel="stylesheet" type="text/css" href="http://www.aiview.com/css/common.css" />
<link rel="stylesheet" type="text/css" href="http://www.aiview.com/css/screen.css" media="screen" title="GetStyleBack" />
<link rel="alternate stylesheet" type="text/css" href="http://www.aiview.com/css/screen-linestyle.css" media="screen" title="LineStyle" />
<link rel="alternate stylesheet" type="text/css" href="http://www.aiview.com/css/screen-clearstyle.css" media="screen" title="ClearStyle" />
<link rel="alternate stylesheet" type="text/css" href="http://www.aiview.com/css/print.css" media="screen" title="PrintPreview" />
<link rel="stylesheet" type="text/css" href="http://www.aiview.com/css/screen.css" media="projection" />
<link rel="stylesheet" type="text/css" href="http://www.aiview.com/css/print.css" media="print" />
<link rel="stylesheet" type="text/css" href="http://www.aiview.com/css/aural.css" media="aural" />
<script type="text/javascript" language="javascript" src="http://www.aiview.com/switch-css.js"></script>

放弃hotmail ，是因为有了gmail ，好处就不在这讨论了，但msn messenger 还在继续使用，大部分联系人还在这上面，只不过登录的邮件不是hotmail 罢了，而是gmail 的。在hotmail 中没有找到自动邮件回复功能，也没有找到自动邮件转发功能，今天登录进去，告诉我可以免费升级到功能更强大的live 邮箱，满怀希望的开始尝试，以上功能依然没有。

我这一抱怨就收不住了，又想起前段时间帮朋友迁移blog，从msn spaces 到mt ，但是发现无法将space 的所有日志导出，rss只包含了最近20条。 

微软的live 战略升级，从某种程度来说是一种受迫性竞争的结果，观察其调整的过程以及域名的混乱，就能看出其进程的痛苦，并且还将延续下去。 

说了这么多微软的坏话，说点好听的吧。新版msn spaces 提供的rss 订阅模块不错，虽然未能与本地发布的日志整合到一起进行显示（同时，你的联系人也无法通过messenger获得你的space 更新通知），但也多了一种额外的选择。我不在msn spaces 写日志，但可以配置一个到aiview.com 的rss 订阅，这样就可以在我的spaces 上显示aiview.com 的文章列表。

Flickr 是非常优秀的在线图片管理工具，提供免费的服务，主要优点：

• 批量剪裁压缩、上传，一步完成，传输速度快
• 图片保存精度较高
• 响应快速的管理界面（Ajax）
• 标签、日期方式索引

免费服务主要的限制：

• 每个月限100M上传流量
  
• 最多管理200张图片，超出可以继续上传，旧的不会被删除，但会被隐藏起来，无法任何方式可以浏览（Flickr Blog除外）。
• 最多只允许建立3个Sets

如果照片不会超过200张，Flickr 是一个非常好的选择；如果会达到数百张，如果选择了Flickr，那么升级到Flickr Pro （$24/Year）几乎是没有选择的，否则转换成本比较高。

我是这样使用Flickr的：

上传图片

除了网页上传，效率更高的方式是下载Flickr Upload 工具 ，集成到鼠标右键菜单，拖放操作，支持批量，十分方便。

浏览图片 

我通常通过Tags 和日期（Archive）来浏览图片，日期分为上传日期（Posted）和拍摄日期（Taken），基本上可以满足需求。

管理图片

管理图片需要先进入Organize，然后通过下面的过滤器筛选出图片列表，拖入当前区域，然后所有的编辑功能都可以通过上面的菜单选择，比如修改标签、权限、日期等等。

权限管理

上传的图片可以指定5 种权限级别：

1. Public - 任何人都可以看
2. Private - 只有自己一个人能看
3. Family - 加入到Family 组的人可以看
4. Friends - 加入到Friends 组的人可以看
5. Friends &Family - Family 或者Friends 组的人都可以看

除了私有（private）与家庭（family），只有单一的Friends 组可以用来作为访问控制，对于多个朋友圈，很明显，不够用。

对此，Flickr 提供了Groups。上传时，无法指定Groups，对于希望受限访问的图片，可以全部选择Private，上传后，针对不同的朋友圈，可以建立相应的Private Groups，然后把相应的图片放入这个Group。然后邀请朋友Join 到不同的Groups，这样就实现了额外层次的访问授权。

上述描述起来有些复杂，不过实际操作非常简单顺手。

2007-04-22  更新

付费Pro 版已经没有了最多3 个Sets 的限制，于是为所有图片以Event 为单位建立了Sets， 对于天数较多的活动可以按地点分为多个Sets，然后建立Collection 包含这几个Sets。 

Sets 默认使用创建顺序显示，可以在Organization Sets 编辑区中利用拖拽调整顺序。

对于所有照片的主题进行归纳（实际是针对Sets），然后建立相应的主题Collections ，把已有的Sets 或者Collection 加入这些主题Collections，注意，Collection 不可以即包含Sets，又包含Collection，只能同时包含一种 。

另外一个小tips，或许是我从前太土了，在Organization 页面的编辑区中，无论是图片，还是Sets，单击均不会有任何操作，双击则可以打开。 

2007-04-23  更新

Blog this 

在Extending Flickr 设置了关联Blog，支持很多种Blog 程序，也包括我使用的MT，仅仅需要指定MT 的远程访问API 接口脚本(http://www.aiview.com/cgi-bin/mt/mt-xmlrpc.cgi)，用户名和密码即可，这个密码不是登录MT 控制台的密码，是API 调用的密码，在MT用户属性页下方设置。

设置完成，既可以点击图片上方的"Blog this" ，输入Title 和Description，直接发布到Blog。有一点遗憾，就是无法指定Entry 的Category 、Tags 以及Basename。

Upload by email 

Flickr 还支持Email 上传图片 ，它会为每一个用户生成一个唯一并且私有的Email 地址（例如：lto30doing@photos.flickr.com），任何知道这个邮件地址的人都可以发布图片到相关联的Flickr，因此对其要保持私密。

Email 的Subject 与Body 会分别作为图片的Title 与Description。 可以在Subject 或者Body 中使用以下的格式 来添加Tags：

tags: flowers "my garden"

但无法指定Sets、Groups 等。

默认的，通过email 发送的图片都是public 的，如果希望使用其他权限 ，可以加后缀到email 地址。比如：

lto30doing+private@photos.flickr.com
lto30doing+friends@photos.flickr.com
lto30doing+family@photos.flickr.com
lto30doing+ff@photos.flickr.com

Blog this by email

额外的，如果希望email 上传的图片都自动发布到已经设置好的Blog，可以在这里设置 ，会得到另外一个email 地址，譬如：

lto30doing2blog@photos.flickr.com

只有Public 的图片才会被自动发布到Blog，其余的就只存放在Flickr。也可以在一封信中包含多个附件，但每一张图片都会生成单独的entry，并share  相同的Title 与Description，所以并不实用。

同样，无法指定Entry 的Category 、Tags 以及Basename。

故障现象

输入域名 mail.google.com 或者 gmail.com 访问Gmail，Firefox 显示空白页，无任何提示，同一时间使用IE 却可以正常访问。

解决方法

造成大多数人无法访问的根源在于下面的第一条，如果无法解决再尝试后面2条。

1. 在域名之前加上 https://，指定 http:// 或者仅输入域名均无法访问
2. 确认Firefox 选项设置中允许SSL连接
3. 如果安装有防火墙，检查设置

在IE 中无需特别指定https，以任意方式输入，均会跳入正常页面。

放弃2.0  

从前使用1.5 遇到过这个问题，升级到2.0 后问题自然消失，也就没有深究。最近发现2.0 响应速度很慢，经常把CPU 用到100％，切换一个Tab 要花费几秒钟，开始以为是Flash 插件惹的祸，安装了Flashblock 禁用Flash 之后，问题依旧，也排除了页面script、打开页面太多等问题。今天装回到1.5 版本，响应慢的问题也随之解决。不过gmail 的问题又回来了，google 了一下，发现问题很普遍 ，答案也多种多样，比如：域名解析、SSL、TLS、防火墙、代理设置、Pop Block，证书等等。但我经过测试，其实真正的原因只有一个，就是大家输入域名的习惯问题，省略了"https://" 或者其中的 "s"。把https://gmail.com 或者 https://mail.google.com 加入收藏夹即可。

对于大多数默认安装的Firefox 1.5 来说，上述其它方面导致问题的概率比较低。

google.com 域名一直存在大陆访问不稳定的问题，mail.google.com 也曾经受累一段时间，不过现在，mail.google.com 已经比较稳定了。在你发现IE 可以访问gmail，但Firefox 无法访问时，十有八九本文可以帮到你。

欢迎大家反馈。 

回头看了看朋友的列表，已经有很多人的名字中都多了这个“i'm”，我一直没在意，因为我还在用7.5的版本。但我发现，美国以外地区的messenger注册用户是不包含在这个活动范围内的，请参考活动官方网页的FAQ 中最后一个Q/A。

Q: Can everyone participate in this initiative?
A: The i’m Initiative is available to everyone in the 50 United States and the District of
Columbia.

不过，官方成员在自己的Blog发布了一篇文章，The i'm Initiative and new secret emoticon ，文章中说明参与“i'm”的美国地区用户与其他国家地区的用户之间的对话（Conversation），对捐献活动是有效的。这篇文章也是一篇不错的“i'm”参与指南。

我在这里 看到的新增慈善组织也未在官方网页中声明，值得商榷。 

新增加的组织：
*wwf World Wildlife Fund for Nature 世界自然基金會
*oxfam The Oxford Committee for Famine Relief 樂施會(協助解決當時世界各地饑荒及貧窮問題)
*care 國際關懷協會
*hsus The Humane Society of the United States 美國人道協會
*acs American Cancer Society 美國癌症協會
*one ONE Campaign-全球消除貧困與對抗愛滋的組織(GCAP)

无论如何， 这个活动看起来还在发展之中，微软还没有设定中止日期的计划，所以今后会有多少个组织参与，并且是否会扩展到美国以外地区也未可知。不过，看着朋友列表上不断多出的“i'm”，还是很开心。

Xiongxiong 告诉我另一种访问维基百科的方法——使用网站代理。打开这个网页，选择任一网站代理，进入后输入维基百科的网址，就可以访问了。上例中使用的是 http://www.un-block.net/

当然，网站代理的作用不仅仅用于访问维基百科，其它受限网站也可以尝试。

美国国防部在《国家工业安全程序操作手册》中对硬盘数据清除作了专门的描述，这个安全标准被称为DOD 5220.22-M（www.dss.mil/isec/nispom_0195.htm）。该手册建议对所要清除的数据区进行三次覆盖，第一次使用一个8位的字符，第二次使用该字符的互补字符（即将二进制位的0、1互换），最后再使用随机字符进行覆盖。

注：NISPOM 是国家工业安全程序（NATIONAL INDUSTRIAL SECURITY PROGRAM）的缩写。

国内外的各种数据清除工具，也有很多按上述类似说法引用了此标准，比如有名的开源软件Darik's Boot and Nuke。出于兴趣，我找到了这个 DoD 5220.22-M 文档（前文的链接无法访问），但无论如何有没有找到被大量资料所提及的数据清除方法。我开始怀疑这个引用的权威性，最后，在wikipedia 找到的文字证实了我的猜测。国内一直无法访问wikipedia ，下面的链接使用了网站代理 。

Misunderstanding as a data sanitization standard

DoD 5220.22-M is sometimes cited as a standard for sanitization to counter data remanence. This is incorrect. The NISPOM covers the entire field of government-industrial security, of which data sanitization is a very small part (about two paragraphs in a 100 page document)^[4]. Furthermore, the NISPOM does not actually specify any particular method. Standards for sanitization are left up to the Cognizant Security Authority. The Defense Security Service provides a Clearing and Sanitization Matrix^[5] which does specify methods; access to the current C&SM is restricted here.

DoD 5220.22-M 一度被作为数据清除的标准进行引用，这是错误的。这个文档覆盖了全部的政府与工业的安全领域，描述数据清除的内容仅占很小的一部分（100页文档中仅有2段文字）。此外，文档中并没有定义任何具体的数据清除方法。数据清除的标准是由Cognizant Security Authority（不知如何翻译）来决定的，可以在国防安全服务（Defense Security Service）提供的一个名为“Clearing and Sanitization Matrix ”的文档中找到。

以下是有关硬盘数据的那部分内容，与前述相符，但不同的是，这不属于DoD 5220.22-M 标准。

d. THIS METHOD NOT APPROVED FOR SANITIZING MEDIA THAT CONTAINS TOP SECRET INFORMATION.

1. Before any sanitization product is acquired, careful analysis to the overall costs associated with overwrite/sanitization should be made. Depending on the contractor’s environment, the size of the drive and the differences in the individual products time to perform the sanitization, destruction of the media might be the preferred (i.e., economical) sanitization method.

2. Overwrite all addressable locations with a character, then its complement. Verify “complement” character was written successfully to all addressable locations, then overwrite all addressable locations with random characters; or verify third overwrite of random characters. Overwrite utility must write/read to “growth” defect list/sectors or disk must be mapped before initial classified use and remapped before sanitization. Difference in the comparison lists must be discussed with the DSS Industrial Security Representative (IS Rep) and/or Information System Security Professional (ISSP) before declassification. Note: Overwrite utilities must be authorized by DSS before use.

值得注意的是，文档中注明：这种数据清除方法并不适用于绝密信息。可见对于美国以外，甚至其它非政府控制机构，其安全性仍然有限。

Google就像快餐，速食并且方便，但食得不干净却容易拉肚，很多人不再关心信息的来源，瞧！Google到这么多相同的搜索结果，就是它了！正所谓三人成虎。

Let's have an overview on HTTPS.

|        HTTPS
|        /  \ 
|    HTTP    SSL    SET
|              \   /
|               PKI

HTTPS is based on HTTP protocal and SSL protocal.

SSL protocal is an implement of PKI standard.

What is PKI?

To discuss HTTTS, we are better to know what PKI is first. It's very important! Here's an article talking about PKI in detail.

PKI, Public Key Infrastructure, is attend to insure the data security transfered over Internet and identify the authentic user.

The public key for ones could be obtained by everyone on Internet, the private key is only kept by the owner. Signing with the public key will insure the data security. Signing with the private key will insure the undeniable.

So it requires both side have theire own keys for insuring secure communication on both direction. However in some situation, it's not easy to get keys on both side, such as B2C, you can't require each visiter getting their keys for using your website.

How does SSL work?

Is there a way to have secure communication both direction without requiring keys on the browser side? The answer is yes, there's SSL. Below's a section from the article Introduction to SSL that describes how SSL works very clearly.

The SSL protocol uses a combination of public-key and symmetric key encryption. Symmetric key encryption is much faster than public-key encryption, but public-key encryption provides better authentication techniques. An SSL session always begins with an exchange of messages called the SSL handshake. The handshake allows the server to authenticate itself to the client using public-key techniques, then allows the client and the server to cooperate in the creation of symmetric keys used for rapid encryption, decryption, and tamper detection during the session that follows. Optionally, the handshake also allows the client to authenticate itself to the server.

Below is brief steps for SSL Handshake(assume it's between Internet Browser and web server.)

Browser side (no keys)          <----->         Server with SSL (keys based on PKI)
--
B   ->  hello, wanna a secure connection                    ->  S
B   ->  my ssl version                                      ->  S
B   ->  my encrypt type                                     ->  S
B   ->  some random data                                    ->  S
B   ->  hello done                                          ->  S
--
B   <-  hello, yeah, i accept                               <-  S
B   <-  some random data                                    <-  S
B   <-	my certificate including my pub-key                 <-  S
B   <-  hello done                                          <-  S
--
B   verify the certificate                                      S
B   generate "premaster secret"                                 S
B   ->  "premaster secret" encrypted with server's pub-key  ->  S
B   generate "master secret" by "premaster secret"              S
B   generate "session keys" by "master secret"                  S
B   ->  I'll send data encrypted by "session keys" at next  ->  S
B   ->  encrypted "I'm ready"                               ->  S
--
B   decrypt "premaster secret" with server's priv-key           S
B   generate "master secret" by "premaster secret"              S
B   generate "session keys" by "master secret"                  S
B   <-  I'll send data encrypted by "session keys" at next  <-  S
B   <-  encrypted "I'm ready"                               <-  S
--
Handshake is finished.

For the steps above, it's not for the case of server reqests the client authenication. Here only discuss the case of none-keys on client side.

We know the keys on server side is only used for exchanging the session key. The session key is the symmetric key that is acctrually used to encrypt/decrypt data between client and server.

I'm not sure how related between the browser and server's random data at their first hello step. At browser generates "premaster secret", it might base on the random data from server. it's my guess. Anyone could give the steps more clear?

Reference

• Introduction to SSL
• PKI 基础
  
• 在Web中使用SSL
  http://www.cnweblog.com/harryyang/archive/2005/06/03/12713.html
  
• How does ssl work?
  http://www.ourshop.com/resources/ssl.html
  

模板：

  <div id="tagcloud"><div class="inner">
<h3>Tags</h3>
<MTTags>
<a class="h<$MTTagRank$>" href="<$MTInclude module="Tag URI"$>" title="<$MTTagCount$> entries"><$MTTagName$></a>  
</MTTags>
</div></div><!--tagcloud--> 

#tagcloud a {
text-decoration: none;
}
#tagcloud a.h1 {
font-size: 200%;
}
#tagcloud a.h2 {
font-size: 180%;
}
#tagcloud a.h3 {
font-size: 160%;
}
#tagcloud a.h4 {
font-size: 140%;
}
#tagcloud a.h5 {
font-size: 100%;
}
#tagcloud a.h6 {
font-size: 90%;
}