| |
|
Transport Layer Security (TLS) and Secure Sockets Layer (SSL) Portal
ICASI is providing the following material to ensure that the Internet community has the most authoritative information on the TLS/SSL vulnerability, and to keep the industry informed about detection, mitigation and remediation options. At right are links to ICASI member companies' product information and how they may be affected by this vulnerability.
To get the latest announcements, alerts, fixes and other important information from our members, follow the links provided below
for each member company.
|
|
|
A protocol-level design flaw in the TLS specification allows an attacker to perform a man-in-the-middle (MITM) attack on sessions protected by Transport Layer Security (TLS) and Secure Sockets Layer (SSL). This vulnerability could allow an attacker who is able to successfully leverage a MITM attack to prepend data to an SSL/TLS-protected session. It does not allow the attacker to read, decrypt, or alter encrypted traffic between client and server.
The attack becomes possible when a TLS renegotiation happens. The most common way for this to occur is when a client requests a resource from the server that requires a different level of security than has already been established. While this is the most common scenario for renegotiation to occur, there are other scenarios under investigation that also trigger a key renegotiation, which can happen from either the client or server.
A typical TLS session with certificate passing is shown in the following figure. The arrows indicate the flow of network traffic between the client and server.
Click here for larger image.
With a MITM attack, the scenario would appear as follows.
Click here for larger image.
The attacker injects malcode to the server when it initiates a request for renegotiation. It passes along the certificate information to the client and sends the client’s certificate to the server. Neither the client nor the server is aware that an attack has taken place.
Top
|
|
Because the renegotiation looks very similar to an initial negotiation session, detecting the attack will be difficult. Here are some options that may help.
Many Intrusion Prevention Systems have the ability to identify when an SSL renegotiation occurs. While this may generate some false positive results, it can be an indicator. Blocking this traffic, however, may cause an adverse reaction to applications, and it should be done with caution.
Some network security devices support SSL decryption if the private keys are loaded on the device. If the entire session can be decrypted by the device, it is possible to detect an attack by capturing and blocking the injection of arbitrary HTTP data.
Monitoring for client-initiated renegotiations and disallowing them through some host-based security solution may be possible. This may not provide a complete detection scenario, and it could cause adverse effects on applications.
Top
|
|
Disabling or preventing renegotiation in the TLS session is one way to mitigate the vulnerability. Because there is no configuration option, however, this action requires a change to the code base.
Web servers can establish a mutual authentication session up front, rather than allowing an anonymous client to connect and then later polling the client for a certificate when a protected resource is accessed. This approach will reduce the need for a TLS renegotiation, as the session will have already established the proper certificates. Note: We don’t recommend that type of “retroactive authentication”. Rather, we strongly recommend establishing the authentication context before an application processes a request for a protected resource.
Another mitigation option will be to correctly utilize access control lists on administrative and management services in the enterprise. Often, administrators rely on TLS for credential handling, which provides an open door in this situation. Deploying access lists to control who can reach back-end services and from where will reduce the attack surface.
Top
|
|
|
|
|
|
|
|
| MEMBER TLS/SSL ADVISORIES |
|
OPEN SOURCE COMMUNITY ADVISORIES |
Though the following is not an ICASI member, such open source links are relevant to the community.
Open Source Community
http://www.openssl.org
|
 |
| |
|
