Forum Discussion
Gregory_Gerard_
Nimbostratus
NimbostratusSSL Protocol Question
Before pursuing a potentially fruitless experiment, I thought I'd ask first. This is about the SSL/TLS protocol.
Given:
1. A client with a valid certificate (issued to each user) -- C
2. A server with a valid certificate (issued for the www.blah.com) -- S
3. An intermediate server between the two (a reverse proxy like an LTM) with the same certificate (or at least a valid certificate for www.blah.com) -- P
I would like P to terminate the SSL session so that I can inspect certain things in the HTTP stream and then if I'm satisfied, get the client to restart SSL on the same TCP connection (I don't want to lose the IP:port association) and reissue the HTTP command.
I don't wish P to impersonate C to S (because it would require the private certificate) nor snoop. Once P is satisfied, it would simply pass the SSL traffic untouched between C and S.
Is this possible in the SSL/TLS state machine?
I realize it might only be possible if there's a response code (302? 503?) that can be given back to the client right before getting it to talk to P so that C will retry the request without cutting the TCP connection.
hoolioCirrostratus
Hi Gregory,
Did you make any progress on this? In terms of LTM, if it is possible, I think you'd need to renegotiate the SSL handshake with the client and then disable the SSL filter if you wanted to pass the client cert through without doing the handshake on LTM.
Aaron
Gregory_Gerard_Thanks for the checkup, hoolio,
No, I've not. I'm just now getting back to this.
Do you think it theoretically possible? Do you think something would sense this as "something funny" and drop the socket connection? Is there a better forum to ask?
I could add two questions.
1. Can the LTM be this authorized man-in-the-middle?
2. Will the LTM freak if it's acting as the server?- hoolioThe major issue I see with this is that I think it would require renegotiating the SSL handshake mid-session. Doing so would mean you'd have to leave yourself open to the recent SSL renegotiation vulnerability described here:
http://extendedsubset.com/?p=8
http://www.links.org/?p=780
http://www.ietf.org/mail-archive/web/tls/current/msg03928.html
If this doesn't frighten you away from the solution, I can try testing a rough example (or at least try to put it down in psuedo code. Let me know what you think.
Aaron - Gregory_Gerard_I'm okay with that. If I understand correctly, people have been turning this off in servers -- the clients are still willing to renegotiate, no?