TLS/1.0, PCI, and a custom message for HTTP response status codes

this is not very elegant, but:

it may be possible to use SSL::respond which allows you to inject raw payload directly into the SSL layer, if this is something you have room to experiment with.

If you go this route however, you may have to make sure that this connection cannot be used for other requests, as I am not sure what effect injecting data into the stream will have on the HTTP profile state machine. So you should consider, including Connection: close in your response, calling HTTP::disable, Dropping the SSL session with SSL::session invalidate, and closing the TCP connection with TCP::close once done.

Very well versed question, kudos for that.

I fiddled around a bit with this in my lab but came to he same conclusion as you did. Maybe you could have an Apache/NGINX server that could do this for you? Or maybe iRulesLX?

Just brainstorming...

/Patrik

A client capable of TLSv1.2 should not connect as TLSv1.0 in the initial instance, so there should never be a valid reason to try to get a browser to upgrade from TLSv1.0 to TLSv1.2.

The Client Hello contains a protocol_version that specifies the lowest version that the client supports, and a client_version that contains the highest TLS version the client supports. The server then responds with the highest version it supports within those two limits. The result is that the client should always connect with the highest TLS version that the client and server can support.

Any client that connects as TLSv1.0 can only connect at TLSv1.0. Your response should be a 200 Response that informs the customer that they need to upgrade their browser.

I'll also add that RFC2817 was intended to drive a TLS protocol upgrade within an unencrypted tcp connection, similar to STARTTLS, allowing virtual hosting for encrypted connections. The adoption of Server Name Indication for SSL has provided a suitable solution to this problem, so RFC2817 is still a proposal after 17 years with no strong drivers for implementation.

Thank you both, BinaryCanary and Patrik for your responses.

To be honest, I do not feel that comfortable to fiddle around with the payload directly on the SSL layer. Unfortunately, I'm not that skilled with iRules. If you have a working example that I could use or modify, I would definitely give it a try.

Regarding the repurposing Apache/Nginx for this, it would be a step backwards for us, because we've just recently migrated the entire website from NGINX/HAPROXY to F5.

Regarding the iRulesLX, I don't even know what it is; googling it right now :)

Here's a quick and easy one for this situation based on the responses above:

when HTTP_REQUEST {
    switch -exact [SSL::cipher version] {
        "TLSv1.2" {
             do nothing
        }
        "TLSv1.1" {
             do nothing
        } default {
            HTTP::respond 403 content {


Access Denied

    You are using a Web browser that is not secure for accessing confidential information. Please upgrade to the most recent version./font>


} "Content-Type" "text/html" Connection close
            TCP::close
            return
        }
    }
}