最近提交了一些关于 docker remote api 未授权访问导致代码泄露、获取服务器root权限的漏洞，造成的影响都比较严重，比如
This issue affected versions of OpenSSL prior to April 2015. The bug causing the vulnerability was fixed on April 18th 2015, and released as part of the June 11th 2015 security releases. The security impact of the bug was not known at the time.
In previous versions of OpenSSL, ASN.1 encoding the value zero represented as a negative integer can cause a buffer underflow with an out-of-bounds write in i2c_ASN1_INTEGER. The ASN.1 parser does not normally create “negative zeroes” when parsing ASN.1 input, and therefore, an attacker cannot trigger this bug.
However, a second, independent bug revealed that the ASN.1 parser (specifically, d2i_ASN1_TYPE) can misinterpret a large universal tag as a negative zero value. Large universal tags are not present in any common ASN.1 structures (such as X509) but are accepted as part of ANY structures.
Therefore, if an application deserializes untrusted ASN.1 structures containing an ANY field, and later reserializes them, an attacker may be able to trigger an out-of-bounds write. This has been shown to cause memory corruption that is potentially exploitable with some malloc implementations.
Applications that parse and re-encode X509 certificates are known to be vulnerable. Applications that verify RSA signatures on X509 certificates may also be vulnerable; however, only certificates with valid signatures trigger ASN.1 re-encoding and hence the bug. Specifically, since OpenSSL’s default TLS X509 chain verification code verifies the certificate chain from root to leaf, TLS handshakes could only be targeted with valid certificates issued by trusted Certification Authorities.
OpenSSL 1.0.2 users should upgrade to 1.0.2c
OpenSSL 1.0.1 users should upgrade to 1.0.1o
Certificate Transparency Offical Site: https://www.certificate-transparency.org/
Certificate Transparency On WikiPedia: https://en.wikipedia.org/wiki/Certificate_Transparency
这两天，关于 Google 对 HTTPS 站点的庇护可算是越来越厉害了，没有加密的网页排名活跃度就没有加密的强....
最近发现小站的速度明显慢了很多，估计就是这个 SSL 搞得....找了点优化方法，顺便修了几个洞洞....
Hey there. This is my frist post in Deamwork. Thank you for your supporting.
Recently, a severe SQL Injection vulnerability was found in Drupal 7. It was fixed immediately (and correctly), but there was a problem. Attackers made automated scripts to attack unpatched sites. Within hours of the release of the vulnerability fix, sites were being compromised. And when I say compromised, I'm talking remote code execution, backdoors, the lot. Why? Like any attack, it's a chain of issues, that independently aren't as bad, but add up to bad news. Let's talk about them: What went wrong? What went right? And what could have happened better? There's a lesson that every developer needs to learn in here.