虚拟专用网络(VPN)已经成为了公司合作伙伴或员工远程安全访问公司资源的事实标准。在本文中，我们将试图解释两种特定的VPN类型，即IPSec VPN和SSL VPN，以及这两种类型应该如何选择。
然而，在深入研究这两个不同类型之前，需要首先对VPN技术进行一个简要的概述。VPN是指有利于远程访问公司资源的一系列技术。这种技术的主要用户，是试图在家或者其他公共场所访问公司资源的公司雇员，以及在公司的基础架构内支持各种系统的合作伙伴或第三方。VPN一般通过在远程站点和公司网络之间建立一个加密通道的方式，利用公共长途IP网络来进行数据传输，这些远程站点包括雇员的笔记本电脑或者第三方系统。 Continue reading »
Report of incident on 15-MAR-2011
An RA suffered an attack that resulted in a breach of one user account of that specific RA.
This RA account was then used fraudulently to issue 9 certificates (across 7 different domains).
All of these certificates were revoked immediately on discovery.
Monitoring of OCSP responder traffic has not detected any attempted use of these certificates after their revocation.
Fraudulently issued certificates
9 certificates were issued as follows:
Domain: mail.google.com [NOT seen live on the internet]
Serial: 047ECBE9FCA55F7BD09EAE36E10CAE1E
Domain: www.google.com [NOT seen live on the internet]
Serial: 00F5C86AF36162F13A64F54F6DC9587C06
Domain: login.yahoo.com [Seen live on the internet]
Serial: 00D7558FDAF5F1105BB213282B707729A3
Domain: login.yahoo.com [NOT seen live on the internet]
Serial: 392A434F0E07DF1F8AA305DE34E0C229
Domain: login.yahoo.com [NOT seen live on the internet]
Serial: 3E75CED46B693021218830AE86A82A71
Domain: login.skype.com [NOT seen live on the internet]
Serial: 00E9028B9578E415DC1A710A2B88154447
Domain: addons.mozilla.org [NOT seen live on the internet]
Serial: 009239D5348F40D1695A745470E1F23F43
Domain: login.live.com [NOT seen live on the internet]
Serial: 00B0B7133ED096F9B56FAE91C874BD3AC0
Domain: global trustee [NOT seen live on the internet]
Serial: 00D8F35F4EB7872B2DAB0692E315382FB0
What didn’t Happen
Our CA infrastructure was not compromised.
Our keys in our HSMs were not compromised.
No other RA was compromised. No other RA user accounts were compromised.
What Happened
One user account in one RA was compromised.
The attacker created himself a new userID (with a new username and password) on the compromised user account. Continue reading »
内容很长,大家慢慢看.
Detecting Certificate Authority compromises and web browser collusion
Posted March 22nd, 2011 by ioerror
Thanks to Ian Gallagher, Seth Schoen, Jesse Burns, Chris Palmer, and other anonymous birds for their invaluable feedback on this writeup.
The Tor Project has long understood that the certification authority (CA) model of trust on the internet is susceptible to various methods of compromise. Without strong anonymity, the ability to perform targeted attacks with the blessing of a CA key is serious. In the past, I’ve worked on attacks relating to SSL/TLS trust models and for quite some time, I’ve hunted for evidence of non-academic CA compromise in the wild.
I’ve also looked for special kinds of cooperation between CAs and browsers. Proof of collusion will give us facts. It will also give us a real understanding of the faith placed in the strength of the underlying systems.
Does certificate revocation really work? No, it does not. How much faith does a vendor actually put into revocation, when verifiable evidence of malice is detected or known? Not much, and that’s the subject of this writing.
Last week, a smoking gun came into sight: A Certification Authority appeared to be compromised in some capacity, and the attacker issued themselves valid HTTPS certificates for high-value web sites. With these certificates, the attacker could impersonate the identities of the victim web sites or other related systems, probably undetectably for the majority of users on the internet.
I watch the Chromium and Mozilla Firefox projects carefully, because they are so important to the internet infrastructure. On the evening of 16 March, I noticed a very interesting code change to Chromium: revision 78478, Thu Mar 17 00:48:21 2011 UTC.
In this revision, the developers added X509Certificate::IsBlacklisted, which returns true if a HTTPS certificate has one of these particular serial numbers:
d8f35f4eb7872b2dab0692e315382fb0
b0b7133ed096f9b56fae91c874bd3ac0
9239d5348f40d1695a745470e1f23f43
d7558fdaf5f1105bb213282b707729a3
f5c86af36162f13a64f54f6dc9587c06
A comment marks the first as “Not a real certificate. For testing only.” but we don’t know if this means the other certificates are or are not also for testing. Continue reading »
2010年5月22日,Google宣布发布https (SSL)加密搜索 将
通过firefox的搜索框进行搜索时,仍然是http开头的地址, 此时我们可以通过firefox的一个转向扩展Redirector来实现自动转向.
Redirector是一个可以自动按照用户定义转向的Firefox扩展，支持通配符和正则两种自定义方式。结合Redirector，在进行Google搜索时，浏览器会自动转向https的加密搜索页面，避免隐私泄露给不信任的方面(当然Google还是会知道你的搜索记录的^_^ )。
使用方法：
到Redirector扩展页面下载安装，重启Firefox浏览器；
在Firefox底部状态栏上的Redirector图标上点击鼠标右键，弹出设置窗口，点击下方的”Add”，添加规则； Continue reading »
2010年5月22日,Google宣布发布https（ssl）加密搜索，发现除了核心搜索业务使用了ssl之外Google快照也开始支持这种加密方式。Google快照的地址是
手动修改地址毕竟不是很方便，幸亏Firefox拥有丰富多样的扩展可以加以利用。Redirector是一个可以自动按照用户定义转向的Firefox扩展，支持通配符和正则两种自定义方式。结合Redirector，在访问Google快照时，浏览器会自动转向https的页面，顺利避开第三方拦截。
使用方法：
到Redirector扩展页面下载安装，重启Firefox浏览器；
在Firefox底部状态栏上的Redirector图标上点击鼠标右键，弹出设置窗口，点击下方的”Add”，添加规则； Continue reading »
cnbeta 感谢藏乐的投递
今天偶然发现，Gmail的设置里面又多了个选项：浏览器连线，可以选择是否永远只使用https，尝试了一下，激活该选项后，进入Gmail都会强制切换https进行连接，该功能增强了访问的稳定性，确实方便了不少。
目前尚不清楚该功能为何时加入，应该又是属于部分用户测试，在Google groups中咨询了一下众多GFans，也只有寥寥几人看到了该功能。
什么是https？
来自维基百科：
https是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，https的安全基础是SSL，因此加密的详细内容请看SSL。
它是一个URI scheme(抽象标识符体系)，句法类同http:体系。用于安全的HTTP数据传输。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。这个系统的最初研发由网景公司进行，提供了身份验证与加密通讯方法，现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。