January 9, 2013
Tame the BEAST (Browser Exploit Against SSL & TLS)
Shift4 works hard to help merchants understand the challenges and threats that they face in the payments processing world. We typically try to explain all the information we publish in plain English so that you don’t have to be an IT genius to understand it. We must warn you: this article breaks from that tradition.
The Browser Exploit Against SSL & TLS (BEAST) vulnerability is a serious threat that affects most of the common Internet browsers in use today. Unfortunately, the fix for this threat requires technical understanding beyond what most of us possess. So, please pass this article on to your IT staff or to your outsourced IT contractors the next time you see them. (You can share it using the “share” button above and selecting the email option.)
Now for the technical details:
Most browsers in use today are vulnerable to Browser Exploit Against SSL & TLS (BEAST).
The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols are commonly used to provide authentication, encryption, integrity, and non-repudiation services to network application protocols such as HTTP, IMAP, POP3, LDAP, SMTP, and others. (In plain English, these are the technologies that secure a Web page so that you see the little lock appear on your browser.) Several different versions of the SSL and TLS protocols have been standardized and are in widespread use. These protocols support the use of both block-based and stream-based ciphers.
A vulnerability in the way the SSL 3.0 and TLS 1.0 protocols select the initialization vector (IV) when operating in cipher-block chaining (CBC) modes allows an attacker to perform a chosen-plaintext attack on encrypted traffic. This vulnerability has been addressed in the specification for the TLS 1.1 and TLS 1.2 protocols, but not all browsers support those versions of TLS and some servers are not configured to specifically negotiate TLS 1.1 and TLS 1.2. For instance, in the newer Windows operating systems using newer versions of Internet Explorer, the protocols are available but are simply not checked (turned on) in the browser’s settings for whatever reason. Also, some other browsers only support TLS 1.1 and many browsers make it difficult to discover what protocol they are using. So if you’re not using IE where you can just check the setting and turn TLS 1.2 on, please contact your browser manufacturer or review their website for additional information.
An attacker with the ability to pose as a man-in-the-middle and to generate specially-crafted plaintext input could decrypt the contents of an SSL- or TLS-encrypted session. This could allow the attacker to recover potentially sensitive information (e.g., HTTP authentication cookies).
There is currently no perfect and complete solution to this vulnerability, but there are some workarounds to reduce the effects of this issue. Some vendors have published specific mitigation advice for the attacks related to it.
The following workarounds can be effective in reducing your attack vector:
- Prioritize the use of the RC4 algorithm over block ciphers in server software. Note that this workaround is not feasible to implement on systems that require FIPS-140 compliance, since RC4 is not a FIPS-approved cryptographic algorithm.
- Shift4 has made this change to all DOLLARS ON THE NET® servers, so that anyone using TLS 1.0 or even SSL3 is protected, but if FIPS compliancy is required, using a browser with TLS 1.1 or TLS 1.2 is the only real solution.
- Enable support for TLS 1.1 and/or TLS 1.2 in the Web browser.
- Enable support for TLS 1.1 in server software. Note that both the Web servers and the client Web browser must support TLS 1.1 or TLS 1.2 for these workarounds to be effective. (Remember all of Shift4’s servers support both TLS 1.1 and 1.2) The session will fall back to an earlier version of the TLS or SSL protocol in the event that either is incompatible with TLS 1.1 or TLS 1.2.
You can rest assured that we here at Shift4 have taken all the necessary precautionary measures to ensure your browsers negotiate the safest and most secure HTTPS sessions possible.
Please visit http://www.kb.cert.org/vuls/id/864643 for more vendor-specific instructions regarding your browser.