Forum Discussion

Nimbostratus

Mar 17, 2017

SSL::PROFILE in HTTP_REQUEST

hello,

I want to match an website with a specific ssl certificate because the multi ssl certif with SNI does not work in my case.

But the "SSL::Profile" does not included in HTTP_REQUEST event.

Do you know how can I realised this irule?

Thanks

Code
when HTTP_REQUEST {
set fqdn1 "website1.com"
    set fqdn2 "website2.com"
    if { [string tolower [HTTP::host]] equals $fqdn1 } {
    SSL::profile "profilefqdn1"     
        SSL::renegotiate
        log local0. "website1"
    }
    if { [string tolower [HTTP::host]] equals $fqdn2 } {
    SSL::profile "profilefqdn2"
        SSL::renegotiate
        log local0. "website2"
    }
}

BIG-IP

devops

iRules

Jeremy_Church_3
Mar 17, 2017
What version of firmware are you using on your F5?

The SSL profile cannot be changed after SSL negotiation has begun on the F5. By the time processing reaches the point of an SSL event, e.g.
CLIENTSSL_CLIENTHELLO
, the profile has already been chosen and can't be changed.

In the
HTTP_REQUEST
event, the SSL negotiation has already taken place and the user would have already received an SSL error if they were going to see one.

If I understand what you're attempting to accomplish, there are a few options.
Multiple profiles
SNI certificate selection prior to 11.6 only inspects the CN of the certificate subject. An option in 11.5 and before is to create a separate SSL profile for each entry in the SAN extensions with the server name field populated in the profile.
Upgrade the F5
Starting in 11.6, the F5 performs inspection based the RFC's description on how a browser should determine if a certificate name is valid. If there is a SAN extension, that is to be inspected and the subject CN ignored. However, most browsers will accept a subject CN or SAN extension match. I have not tested if the F5 ignores the CN in the presence of a SAN extension in 11.6 or after.
Inspect Hello
Another option is to inspect the Hello packet directly using
TCP::collect
and
CLIENT_DATA
event, but that is resource intensive and complicated. I won't go into details, but it is an option.

MattB_MA_170307
Nimbostratus
Mar 17, 2017
Are the SSL Profile names in quotes? Per https://clouddocs.f5.com/api/irules/SSL__profile.html they dont appear to be, and I know that my iRules that have profile switching don't make use of them.
¬†

Beyond that, if you tail the log, can you see that your if statements are being triggered? Meaning that if you go to website1.com, do you at least seel "website1" in the log?
¬†
Exploitation_Ca
Nimbostratus
Mar 17, 2017
I don't see the second website information in the log, because the session is aborted. he waits the certificate.

Can I use HTTP::respond to check if the session return me 500 error code and I use SSL::Profile to specify a new certificate?
Jeremy_Church_3
Cirrus
Mar 17, 2017
What version of firmware are you using on your F5?

The SSL profile cannot be changed after SSL negotiation has begun on the F5. By the time processing reaches the point of an SSL event, e.g.
CLIENTSSL_CLIENTHELLO
, the profile has already been chosen and can't be changed.

In the
HTTP_REQUEST
event, the SSL negotiation has already taken place and the user would have already received an SSL error if they were going to see one.

If I understand what you're attempting to accomplish, there are a few options.
Multiple profiles
SNI certificate selection prior to 11.6 only inspects the CN of the certificate subject. An option in 11.5 and before is to create a separate SSL profile for each entry in the SAN extensions with the server name field populated in the profile.
Upgrade the F5
Starting in 11.6, the F5 performs inspection based the RFC's description on how a browser should determine if a certificate name is valid. If there is a SAN extension, that is to be inspected and the subject CN ignored. However, most browsers will accept a subject CN or SAN extension match. I have not tested if the F5 ignores the CN in the presence of a SAN extension in 11.6 or after.
Inspect Hello
Another option is to inspect the Hello packet directly using
TCP::collect
and
CLIENT_DATA
event, but that is resource intensive and complicated. I won't go into details, but it is an option.