Table of Contents
Advertisement
Release Notes
3.5. Directory Server Information
All subsystems require access to Red Hat Directory Server 7.1 on either the local machine (if it is also
a 32-bit Red Hat Enterprise Linux platform) or a remote machine (acceptable platforms are 32-bit Red
Hat Enterprise Linux 4, 32-bit Solaris 9 for SPARC, or 64-bit Solaris 9 for SPARC).
3.6. Source RPMs
Red Hat Certificate System 7.3 is not an open-source product. Consequently, source RPMs are only
available for third-party packages.
NOTE
Several of these third-party packages may issue warnings when they are installed
because they may contain the UID and GID of their original packager.
4. Known Issues
4.1. Reconfiguring the Red Hat Certificate System Subsystems to
Prevent a Potential TLS-Related Man-in-the-Middle Attack
Transport Layer Security (TLS) is a protocol which establishes a secure connection between a client
and a server. Marsh Ray of PhoneFactor discovered a flaw in the TLS protocol itself which could allow
an attack to insert plain text into an existing session during a TLS renegotiation operation.
The Educated Guesswork blog has a good description of this kind of attack at
www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html.
Either a client or a server may request a renegotiation of an existing TLS/SSL session (for instance,
to renew session encryption keys or to use different cipher suite). When TLS/SSL is used to secure
access to an HTTP service and a client attempts to access some protected resource, server-initiated
renegotiation asks client to authenticate with a certificate.
However, the TLS/SSL protocols did not use any mechanism to verify that session peers do not
change during the session renegotiation. Therefore, a man-in-the-middle attacker could use this flaw
to open TLS/SSL connections to the server, send attacker-chosen request to the server, trigger the
renegotiation (either by directly requesting it or by attempting to access protected resource, resulting
in server-initiated renegotiation) and splice victim's initial connection attempt to an existing TLS/
SSL session. Depending on the application-layer protocol, this may lead to attacker request being
performed by the server as if authenticated using victim's credentials or using data from victim's
request. After the renegotiation, attacker can no longer decrypt communication between the client and
the victim, so this attack is also referred to as a "blind prefix injection" attack. Eric Rescorla's blog post
"Understanding the TLS Renegotiation Attack" provides additional details about this flaw.
In Certificate System, this kind of session renegotiation occurs if a user connects to an end-entity port
that doesn't require client authentication, but then attempts to submit a certificate enrollment form for
an enrollment profile that requires client authentication. The Certificate System server requests and
then parses a client certificate for the user.
For both client-initiated and server-initiated renegotiation to be fixed, then both the client and server
need to be updated to apply the resolution in RFC 5746. For Certificate System subsystems, this
10
http://
Advertisement
Table of Contents
