Web Server 7 and the SSL/TLS Vulnerability
The recent SSL/TLS protocol vulnerability has been thoroughly covered
in the press. Refer to the above link for the formal vulnerability
report and refer to any one of many articles on the web for commentary
While the vulnerability is at the SSL/TLS protocol level and impacts
all products which support SSL/TLS renegotiation, this article covers
it only from the Web Server angle.
Please keep in mind this is not a bug in Web Server nor a bug in NSS.
It is flaw in the SSL/TLS protocol specification itself.
What is the vulnerability?
To quote from the CVE report:
[The protocol] 'does not properly associate renegotiation
handshakes with an existing connection, which allows
man-in-the-middle attackers to insert data into HTTPS sessions,
and possibly other types of sessions protected by TLS or SSL, by
sending an unauthenticated request that is processed retroactively
by a server in a post-renegotiation context, related to a
"plaintext injection" attack'
In terms of the Web Server, this means that the MITM
(man-in-the-middle) attacker may interact with the web application
running on the Web Server for a while and later "hand off" the same
SSL/TLS session to the legitimate client in such a way that as far as
the Web Server is concerned it was same [legitimate] client all along.
This "hand off" occurs when a renegotiation is done on the SSL/TLS
connection. Note that renegotiation may be triggered by either the
client(attacker) or the Web Server. The protocol is vulnerable either
way, regardless of which party triggers the renegotiation (contrary to
some popular belief).
A key point is that the vulnerability is at the SSL/TLS protocol
level, in other words, at a lower level than the HTTP connection
layer. Even if your Web Server is not configured to ever perform
renegotiation explicitly, renegotiation can still occur and thus your
site can still be vulnerable. There is nothing you can do to configure
Web Server (prior to 7.0u7) to disable renegotiation from happening.
This is why you must upgrade to Web Server 7.0u7 (or later).
The rest of this article goes into more detail for the curious, but
the bottom line remains that it is time to upgrade to Web Server 7.0u7
Is My Web Server Vulnerable?
If you are not using https at all, your site is not vulnerable (of
course, if the site is sending and receiving any sensitive data in
clear text it is vulnerable to plenty of other problems, just not this one!)
If your Web Server (pre-7.0u7) is configured to use https and it is
not configured to require client-auth, it is open to the renegotiation
If client-auth is 'required' then that server is not vulnerable.
Specifically, you are safe only if the http-listener has this in its
When client-auth is 'required' it means that the Web Server will
require the client to provide a valid certificate as part of the
initial handshake when establishing the SSL/TLS connection. If no
valid client certificate is provided at that point, the connection is
never established. Because the HTTP-level connection is never created,
there is no window of opportunity for the attacker to send data before
the client authentication takes place, defeating the attack.
In short, if you are running Web Server 7.0u6 or earlier and using
https the only way to remain safe from this attack is to set
<client-auth>required</client-auth> on all the <http-listener>
elements which use <ssl>.
Unfortunately there is a significant drawback to doing this. Now all
the content on your https site requires client-cert authentication.
Clients who access the site without a valid certificate not only
cannot read even the home page, they also can't even get a useful
error page. Because the connection attempt is rejected before it ever
gets established at the HTTP level, it is not possible for the Web
Server to redirect the client to a helpful error page. Your site is
safe but the user experience will most likely not be acceptable.
Web Server 7.0u7 - What's New
Earlier I pointed out that there is nothing you can do to disable
renegotiation from occurring. Even if the Web Server is never
configured to trigger renegotiation, it can still happen transparently
thus it remains vulnerable.
Web Server 7.0u7 includes the latest release of NSS (NSS 3.12.5). The
significant change in this release is that SSL/TLS renegotiation is
completely disabled. Any attempt to trigger renegotiation (whether
initiated by the Web Server itself or by the remote client) will cause
the connection to fail.
The good news is that by simply upgrading to Web Server 7.0u7 your
site is now automatically safe from this vulnerability.
Whether there are bad news or not depends on whether your site had any
legitimate need for renegotiation. If it did not, there is no bad
news. Your site is now safe from this vulnerability and everything
continues to work as before.
On the other hand if your site did make use of renegotiation, that
capability is now broken.
Does My Site Use Renegotiation?
There is no check box anywhere that says the server needs or does not
need renegotiation, so until this vulnerability became public you may
have not given any though to whether your Web Server configuration is
The Web Server uses renegotiation when the web application is
configured to require a client certificate for some parts of the
content but not for all. This permits the client to request the
anonymous areas without presenting a client certificate. If the
client clicks on a link to a protected area the Web Server then
triggers a renegotiation to obtain the client certificate.
There are a couple of ways to configure this in Web Server 7:
If the server.xml <client-auth> element is not set to 'required' and
your web application uses either of the above mechanisms to trigger
the need for a client certificate for some parts of the application,
then the Web Server is using renegotiation. This means this
functionality will be broken after upgrading to Web Server 7.0u7.
Unfortunately there is no way around this. The current SSL/TLS
renegotiation is fundamentally broken so it cannot be used safely.
But I Like It When My Web Site Is Vulnerable To Attacks!
If you absolutely must have renegotiation support, please reread this
document from the top. There is no safe way to enable renegotiation,
if you enable it your site is vulnerable.
If despite everything you still feel you must have the broken
renegotiation support, it can be done as follows:
Environment variable: NSS_SSL_ENABLE_RENEGOTIATION
Values: "0" or "Never" (or just "N" or "n") is the default setting
disables ALL renegotiation
"1" or "Unlimited" (or just "U" or "u")
re-enables the old type of renegotiation and IS VULNERABLE
If you set NSS_SSL_ENABLE_RENEGOTIATION=1 in the environment from
where you start the Web Server 7 instance, renegotiation will work as
it did in Web Server 7.0u6 and earlier. Which is to say, you'll be
vulnerable to attacks again. Obviously, we never recommend doing this.
The current state is very unfortunate. Renegotiation was a useful
mechanism for requesting client certificate authentication for only
some parts of the web application. Now there is no way to do so
safely. As noted earlier this vulnerability is not a bug in the Web
Server implementation of SSL/TLS, it is a fundamental flaw in the
protocol specification. Therefore there it can only be fixed at the
protocol level (see next section). Until that happens there is nothing
the Web Server can do to provide a safe implementation so it is a fact
of life that renegotiation can no longer be used.
Here is one possibility which may ameliorate the limitation for some
sites. It requires some site refactoring work but may offer relief
(thanks to Nelson Bolyard of the NSS team for the idea):
Consider refactoring your https content into two separate
- http-listener ls1: port 443 (standard SSL port), no client-auth
- http-listener ls2: some other port (say, 2443), client-auth=required
Because you have upgraded to Web Server 7.0u7, listener ls1 is safe
because renegotiation is disabled. Listener ls2 is also safe because
it has client-auth=required.
Refactor your web application so that whenever a link into a
protected area is accessed it it sent to https://example.com:2443/...
(where example.com is your site) instead.
This allows clients to access the anonymous content on
https://example.com/ and also allows requesting client certificate
authentication when needed, on https://example.com:2443/, all while
avoiding any use of renegotiation.
If you decide to try this approach feel free to share your experiences
on the Web Server forum. Keep in mind that if your Web Server is behind a reverse proxy or a load balancer or other such frontend, you'll need to arrange so the proper ports are reached as needed.
Work is underway on an enhanced TLS renegotiation protocol which will
not be susceptible to the vulnerability. For info refer to:
As soon as the work is complete and a stable implementation is
released, a future update of Web Server 7 will contain support for
this enhanced renegotiation. Further details on it will be documented
at that time.
Keep in mind that both the server and the clients will need to be
upgraded in order to communicate via the new protocol. While Web
Server 7 will be upgraded as soon as possible and browsers which use
NSS (such as Firefox) will likely also be upgraded promptly, there
will remain a vast installed base of older browsers which will not be
compatible with the enhancements for a long time. Some clients, such
as those in embedded devices, may well never be upgraded. Therefore,
a full transition to the new renegotiation will take considerable