Forum Discussion
soymanue
Nimbostratus
Apr 05, 2011Certificate Authentication issue with Firefox 4
Hi
We have a SSL site. Once you have connected, you must get authenticated to access a a part of the site. You can be authenticated with user and password, but you can also choose to be authenticated with a certificate.
To do that whe have this iRule (based on an example found in devcentral):
Initialize the variables on new client tcp session.
when CLIENT_ACCEPTED {
set collecting 0
set renegtried 0
}
Runs for each new http request
when HTTP_REQUEST {
set uri [string tolower [HTTP::uri] ]
if { $renegtried == 0
and [SSL::cert count] == 0
and ([HTTP::uri] matches_regex {^/certauth.jsp$}) } {
HTTP::collect
set collecting 1
SSL::cert mode request
SSL::renegotiate
}
}
After a handshake, we log that we have tried it. This is to prevent
constant attempts to renegotiate the SSL session. I'm not sure of this
feature; this may in fact be a mistake, but we can change it at any time.
It is transparent if we do: the connections only work slower. It would,
however, make BigIP detect inserted smartcards immediately. Right answer
depends on the way the feature is used by applications.
when CLIENTSSL_HANDSHAKE {
if { $collecting == 1 } {
set renegtried 1
Release allows the request processing to occur normally from this
point forwards. The next event to fire is HTTP_REQUEST_SEND.
HTTP::release
}
}
Inject headers based on earlier renegotiations, if any.
when HTTP_REQUEST_SEND {
if {not ([catch {SSL::cipher version} result]) && $result ne "none"}{
clientside {
HTTP::header remove "WL-Proxy-Client-Cert"
if certificate is available, send it. Otherwise, send a header
indicating a failure, if we have already attempted a renegotiate.
catch {SSL::cert count } numbercerts
if { $numbercerts > 0 } {
set client_cert [SSL::cert 0]
HTTP::header insert "WL-Proxy-Client-Cert " [X509::whole [SSL::cert 0]]
HTTP::header insert "WL-Proxy-Client-Cert " [ join [string trim [string map { "-----BEGIN CERTIFICATE-----" "" "-----END CERTIFICATE-----" ""} [X509::whole [SSL::cert 0]] ] ] "" ]
log local0. "\[HTTP::header value WL-Proxy-Client-Cert\]: [HTTP::header value WL-Proxy-Client-Cert]"
foreach aHeader [HTTP::header names] {
log local0. "[IP::client_addr]:[TCP::client_port]: $aHeader \
([string length [HTTP::header value $aHeader]]): [HTTP::header value $aHeader]"
}
} elseif { $renegtried == 1 } {
This header has some debug value: if the FAILED header is not
present, BigIP is probably not configured to do client certs
at all.
HTTP::header insert "WL-Proxy-Client-Cert_FAILED" "true"
}
}
} else {
log local0. "\$result: $result. Redirecting unencrypted request."
}
}
After the upgrade to 10.2 the cert authentication stopped working until we enabled ssl renegotiation.Now we are suffering the same problem with Firefox 4: the certificate authentication doesn't work until we enable SSL Renegotation in the browser settings (https://support.mozilla.com/es/ques...wer-158847).
Is there any workaround? Is there any way to keep the certificate authentication without enabling SSL Renegotiation?
Thank you in advance
5 Replies
- Colin_Walker_12Historic F5 AccountI'm not sure I follow your issue. After the upgrade to 10.2 you started getting bad results? Can you give more details about what's happening and under what circumstances you're seeing failures? Are there any log entries?
Colin - hoolio
Cirrostratus
Hi Manuel,
Per this Firefox article, https://wiki.mozilla.org/Security:RenegotiationControl, Mozilla has implemented something clever to try to force websites who want to do SSL renegotiation to support RFC5746 (which fixes the SSL renegotiation vulnerability described in CVE-2009-3555).
So I think the gist it is, until LTM supports RFC5746, FF4 clients will need to manually enable an option in the browser to allow connections to a virtual server which tries to initiate renegotiation. F5's ID for this issue is 223836. It is not currently fixed. If you'd like to escalate this I suggest opening a case with F5 Support and talk with your account manager.
Aaron - Joel_Moses
Nimbostratus
Hoolio's right. No way around this until RFC-5746 support, unless you want to collect the client certificate as part of the initial SSL transaction (no more asking for cert only for certain URIs, then).
The only other way I can see around this in the meantime is to set up another VIP/hostname with the clientSSL profile set to "require" the client certficate, and redirect users who migrate to the /certauth.jsp URI to the new VIP/hostname. You can then modify the iRule to remove URI detection and renegotiation and just set the WL-header values. If you want to get really fancy, you could do this just for Firefox 4 users via User-Agent. - hoolio
Cirrostratus
I think we have RFC5746 support in v11.0 beta2. And I think there are plans for a 10.2.x hotfix. But more cases/account manager calls would probably help with the 10.2.x fix.
Aaron - nitass
Employee
ID 223836 - TLS extension for secure renegotiation (Formerly CR 132172) is implemented in solstice/v11.
i've already asked ES whether it's possible to have it in v10.x but haven't yet got answer.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
DevCentral Quicklinks
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
Discover DevCentral Connects