We use email every day, be it sending them for work or personal reasons or getting a thousand and one emails advertising everything from something you are interested in helping a foreign prince distribute their wealth. One way that you can be protected when sending emails is to send encrypted emails, something which has risen in use by 25% for Gmail users.
What caused this spur of encrypted emails? Google stated last year that they would start flagging up emails which were unencrypted, warning users which providers and emails were being sent from services that supported TLS encryption. This change came into effect in February this year, the end result of which was the 25% increase in encrypted emails that Gmail has reported in the last month.
Google isn’t acting alone on this, with Comcast, Microsoft, Yahoo and other companies in the industry looking to create SMTP, a new standard that could be used to help protect emails from man-in-the-middle attacks.
Combining all these with their recent push on security updates in Chrome and Android, including their use of two-factor authentication encryption and warning people about state-sponsored attacks on accounts, it’s becoming more and more clear that even in the digital world, companies want your private information to remain private.
A new vulnerability has been discovered by security researchers that could be used to allow eavesdroppers to spy on the traffic between users and as many as one-in-three HTTPS servers. The problem arises due to the fact that many HTTP servers still support the outdated and now-insecure Secure Sockets Layer (SSL) version 2 protocol. SSLv3 succeeded SSLv2 back in 1996, however, it was only officially deprecated by 2011, which has resulted in its continued presence in servers. Even SSLv3 has since been replaced with newer, more secure Transport Layer Security (TLS) versions 1.0, 1.1 and 1.2.
While SSLv2 is totally unsuitable for encrypted communications, it wasn’t until now that security researchers have thought that its continued support in servers would pose a security threat as most modern clients such as web browsers and others capable of TLS communications no longer support it. A newly released paper has found this assumption to be false by showing that a server supporting SSLv2 can be exploited by attackers to decrypt any traffic from its clients, even those using the most up-to-date TLS protocols.
The attack, which has come to be known as DROWN (Decrypting RSA with Obsolete and Weakened eNcryption), has a number of prerequisites, but unlike some vulnerabilities, they remain practical to execute. Firstly, the server must either support SSLv2 or share its private key with another server that does, which is common in many organizations that share a key across both web and email servers. With this satisfied, the attack must then monitor several hundred encrypted communications between the victim and the server, whether by simply observing over a long period or using malicious code to force numerous connections to be repeatedly made with the sever. Even the requirement that the handshake must use the RSA key exchange algorithm is simple, as it is the most commonly used key exchange in TLS implementations.
Armed with this information, the attacker then connects to the server via SSLv2 multiple times using specially crafted handshake messages that contain modifications of the RSA ciphertext captured during the victim’s TLS connections. These connections will cause the server to leak further information regarding the secret keys used during the TLS connections despite failing. It was calculated that even in a worst-case scenario, an attacker would need to erform roughly 40,000 probe connections and 2^50 computations to decrypt one out of 900 observed TLS connections. It was estimated by the researchers that running the calculations for the attack on Amazon’s EC2 cloud computing platform would cost around $440. The attack is even significantly easier if the server is running a version of OpenSSL library that contains two known flaws.
As many as 17% of all HTTPS servers are directly vulnerable to the attack, with 25 percent of SMTP with STARTTLS servers, 20 percent of POP3S and IMAPS servers and 8 percent of SMTPS also vulnerable. Even amongst HTTPS servers that did not directly support SSLv2, those that shared their private keys with other web servers supporting SSLv2 raised the overall percentage of vulnerable servers to 33%. Thankfully, while DROWN attacks may expose critical information such as login or banking credentials, the attack would have to be executed from scratch for every user and the server’s long-term private keys are not exposed, only the keys negotiated for specific sessions.
Server administrators have been urged to ensure that SSLv2 has been disabled on their servers, including any sharing private keys. Instructions on how to do so have been provided by the researchers for the most common web servers and TLS libraries. For those unsure whether their server is vulnerable, even with SSLv2 disable, a tool has been released to determine is a server is vulnerable and affected by key reuse.
It is scary to think that some of the websites vulnerable to this issue include big names used in the everyday lives of many such as yahoo.com, weibo.com, buzzfeed.com, weather.com, flickr.com, and dailymotion.com.
The OpenSSL cryptographic library was recently updated in response to a high severity vulnerability that was found its code. The vulnerability made it possible for attackers to get hold of the decryption key used for traffic secured by HTTPS and other transport layer security methods.
Thankfully, while the consequences of the vulnerability were high, the flaw can only be exploited when a very specific set of conditions are met. For starters, only version 1.0.2 even contains the vulnerability. The application reliant on it must then use groups based on the digital signature algorithm (DSA), which then generate ephemeral keys using the Diffie-Hellman key exchange. Server applications typically re-use the same private Diffie-Hellman exponent for the lifetime of the server process, by default. The result is that the server’s encrypted traffic then becomes vulnerable to a key-recovery attack, the same being the case in configurations that rely on a static Diffie-Hellman cipher suite.
When the requirements are met, an attacker can make a barrage of handshake requests to the vulnerable endpoint system. With enough requests, partial secret values can be obtained and combined using the Chinese Remainder Theorem to calculate the encryption key. More extensive information on the attack and vulnerability can be found on Antonio Sanso’s blog and as part of an OpenSSL security advisory.
Thankfully, the majority of mainstream OpenSSL and DSA-based Diffie-Hellman reliant applications don’t seem to meet these requirements. For example, the common Apache Web Server enables the SSL_OP_SINGLE_DH_USE option, which causes different private exponents to be used across the process’ lifespan. Meanwhile, the two main forks of OpenSSL, do not have the vulnerability present in them. Google’s BoringSSL removed the option for SSL_OP_SINGLE_DH_USE some months earlier, while in LibreSSL, it was deprecated less than a week ago. Anything that uses a static cipher suite risks continuing to be vulnerable, however.
Sanso reported the bug privately to the OpenSSL project maintainers on the 12th of January, meaning it took only two weeks for them to identify, test and roll out a fix. Curiously, at the time of the bug being reported, a fix relating to the re-use of Diffie-Hellman exponents had already been committed to the OpenSSL but was yet to be part of a release. For obvious security reasons, details of the vulnerability were not publicly released until a patch was already available so that would-be attackers would not be aware of the attack vector until it was already removed. While it may only affect edge-cases, if you’re running a server that relies on OpenSSL 1.0.2, you should be sure to update to 1.0.2f and those on 1.0.1 should install 1.0.1r although support for 1.0.1 is finishing at the end of this year.
The video streaming giant, Netflix will soon be using the HTTPS protocol to encrypt its customer streams. A great plan that helps ensure that what they watch stays secret. This change will leave Amazon as one of the largest encrypted sites.
Turning on HTTPS on Netflix’s vast network of servers has been an impressive feat by the Netflix tech teams; This was because the demands of implementing TLS are rather severe in comparison to standard HTTP.
Each Netflix server has a 64bit Intel Xeon processor and runs the FreeBSD operating system. A single server can store up to 120 terabytes of data and can server up to 40,000 long length connections. This means the server can use up to 40 gigabits per second of bandwidth.
Netflix attempted to change this six months ago. They changed several dedicated servers to use the TLS protocol to a select set of end users. They compared the performance results with a similar range of end users and the same amount of dedicated servers and saw as much as a 53% capacity hit. The end result of the test finding that this was because of the extra power that encryption requires. The change meant that some of the streaming optimizations were lost.
On Wednesday the director of streaming standards, Mark Watson announced that it was ready to begin rolling out HTTPS for both the website and the content itself. Browser tests will be at scale in the next three months and the full website should be complete in the next coming year.
The performance impact has been restricted due to some TLS optimizations that the Netflix engineers crafted for high performance FreeBSD applications.
Netflix’s entry into the HTTPS world comes as security advocates have been calling on all websites to encrypt their traffic. The force behind these requests is that if HTTPS is used then it can stop state sponsored attacks that countries such as the US and China launch from the internet backbone.