[foaf-protocols] ssl renegotiation for foaf card protocols
home_pw at msn.com
Fri Nov 25 11:44:37 CET 2011
I found it useful to see the history of thinking in windows, when server-side (API programmable) ssl renegotiation was added, post 2000. http://www.derkeiler.com/Newsgroups/microsoft.public.platformsdk.security/2003-09/0047.html it you are building protocols, one can see the assumptions made. One contrasts all that with what one can achievve in scripting terms, where one can always drop ongoing TCP connections that are the bearer for an SSL conenction, in an SSL session. Closing a channel which will force a full handshake (with cert verify) should the next URI presented be deemed by the App's OnReceive event handler to be a protected resource (as defined by script) and a server.transfer recasts the URI in the pipeline to (a hidden) one to which a SSL negotiate requirement has been specified. Upon streaming the response, one adds connection=close to the responder header collection, to force a new certverify for the next protected resource (as ocne again sever.transfered to the hidden endpoint that induces the SSL handshake renegotiation before considering the original post to the original URI.) here is some further background, particular on those who insist on using Apache. http://blogs.msdn.com/b/ieinternals/archive/2011/03/26/https-and-connection-close-is-your-apache-modssl-server-configuration-set-to-slow.aspx The blog shows some visual tools on windows - useful for performance engineering when considering connections, sessions, and handshakes in websites.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the foaf-protocols