Disable HTTP2 profile from iRule?
Hi! We will implement HTTP2 since it's supported in version 12. There is one iRule assigned to VIP that requires SSL renegotiation. Renegotiation conflicts with HTTP2 and gives SPDY protocol error. This iRule asks for a client certificate from card reader for a specific URL and country. It's easy to select another SSL profile with renegotiation enabled for this specific country, but it would be better to use another SSL profile for this specific URI only. HTTP URI is not allowed within CLIENT_ACCEPTED, but we can live with disabling HTTP2 for a country if there is no way to accomplish this. The most important is to figure out how to disable HTTP2 profile on the VIP for this URL or country. I have not yet found a solution for this. WAM::disable is not working. Any help is highly appreciated because this is a blocker now for enabling HTTP2. iRule: Initialize the variables on new client tcp session. when CLIENT_ACCEPTED { set collecting 0 set renegtried 0 Find out country tag set CountryID "[whereis [IP::client_addr] country]" Use SSL profile with renegotiation enabled if {$CountryID eq "EE"} { SSL::profile with_renegitiation_enabled } } Runs for each new http request when HTTP_REQUEST { /player/identification/eid/start triggers client cert renegotiation if { $renegtried == 0 and [SSL::cert count] == 0 and (([HTTP::uri] starts_with "/player/identification/eid/start") || ([HTTP::uri] starts_with "/player/authentication/authentication/loginEid")) } { Collecting means buffering the request. The collection goes on until SSL::renegotiate occurs, which happens after the HTTP request has been received. The maximum data buffered by collect is 1-4 MB. WAM::disable 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 { clientside { Security: reject any user-submitted headers by our magic names. HTTP::header remove "ID-EE-SSL_CLIENT_CERTIFICATE" HTTP::header remove "ID-EE-SSL_CLIENT_CERTIFICATE_FAILED" if certificate is available, send it. Otherwise, send a header indicating a failure, if we have already attempted a renegotiate. if { [SSL::cert count] > 0 } { log local0. "Client Certificate: [X509::subject [SSL::cert 0]]" HTTP::header insert "ID-EE-SSL_CLIENT_CERTIFICATE" [X509::whole [SSL::cert 0]] } 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 "ID-EE-SSL_CLIENT_CERTIFICATE_FAILED" "true" } } }
HTTP/2 and Request Logging
On our BIG-IP (Version 12.1.2 Build 0.93.249) we tried adding HTTP/2 Profile to one vServer. The Browser answered with "ERR_CONTENT_DECODING_FAILED". After some troubleshooting, we identified the "Request Logging Profil" as the main cause. After reading this article I tend to accept that the high speed logging (hsl) writes variables before the HTTP_Request event and therefore can't handle the HTTP/2 Stream. Is the only way to log requests while using HTTP/2 via an iRule or is this issue fixed in later BIG IP Versions?
