Re: mod_ssl SSL session timeout
On Fri, Jun 13, 2014 at 5:19 PM, Eric Covener cove...@gmail.com wrote: On Fri, Jun 13, 2014 at 11:03 AM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote: I would prefer to keep SSLSessionCacheTimeout the only directive and use that also for the default timeout of any created session even if not cached server side. Second best IMHO would be a separate +1 to this SSLSessionTimeout, which would be implemented totally independent of SSLSessionCacheTimeout. Only +0 here. +1 +1
Re: mod_ssl SSL session timeout
On 13.06.2014 16:55, Rainer Jung wrote: Now since a long time most clients do no longer rely on the server caching the sessions. Instead they use TLS session resumption (RFC 5077). without server-side state/stateless is actually the important term from this RFC (session resumption is a standard protocol feature). Currently mod_ssl does not provide a way to control the time how long such a ticket may be used by the client. As far as I can see, there is no specific API in OpenSSL for that, but there is a general API allowing to set a session timeout that is checked whenever a session is reconstructed. What OpenSSL function do you have in mind? SSL_SESSION_set_timeout? AFAICT, t1_lib.c:tls_decrypt_ticket simply restores the (relative) timeout for the SSL_SESSION, which is set to 5 minutes by default... but if I'm understanding correctly, you are concerned about clients reusing old tickets, is that correct? (If so, then I guess there's currently no other way than switching to a new ticket encryption key, see also [1]). Kaspar [1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201308.mbox/%3C2013082727.GA7331%40redhat.com%3E or https://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3C52248C40.7070206%40opensslfoundation.com%3E
Re: Memory leak in mod_ssl ssl_callback_TmpDH
On 02.06.2014 20:49, Ruediger Pluem wrote: Joe Orton wrote: On Wed, May 28, 2014 at 10:10:16PM +0200, Ruediger Pluem wrote: Thanks, but I missed some stuff during review: 1. We don't need to have two DH pointers in make_dh_params Doh! 2. There possible frees on NULL pointers in free_dh_params: This is unnecessary because DH_free() does that already, but that deserves a comment too. I'll fix this with your patch for (1) shortly, thanks! Are you waiting for any action from my side? Just want to avoid that we wait for each other and deadlock :-) Just a quick reminder... I think it's important to backport r1597349/r1598107 + the additional adjustment for 2.4.10 (happy to vote once it's settled on trunk). Kaspar
Re: mod_ssl SSL session timeout
On 14.06.2014 10:23, Kaspar Brand wrote: On 13.06.2014 16:55, Rainer Jung wrote: Now since a long time most clients do no longer rely on the server caching the sessions. Instead they use TLS session resumption (RFC 5077). without server-side state/stateless is actually the important term from this RFC (session resumption is a standard protocol feature). Currently mod_ssl does not provide a way to control the time how long such a ticket may be used by the client. As far as I can see, there is no specific API in OpenSSL for that, but there is a general API allowing to set a session timeout that is checked whenever a session is reconstructed. What OpenSSL function do you have in mind? SSL_SESSION_set_timeout? I was hoping SSL_CTX_set_timeout() would do the trick. AFAICT, t1_lib.c:tls_decrypt_ticket simply restores the (relative) timeout for the SSL_SESSION, which is set to 5 minutes by default... but if I'm understanding correctly, you are concerned about clients reusing old tickets, is that correct? (If so, then I guess there's currently no other way than switching to a new ticket encryption key, see also [1]). Yes that's my concern. I will give SSL_CTX_set_timeout() a try over the weekend. Kaspar [1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201308.mbox/%3C2013082727.GA7331%40redhat.com%3E or https://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3C52248C40.7070206%40opensslfoundation.com%3E Regards, Rainer
Re: mod_ssl SSL session timeout
On 14.06.2014 11:44, Rainer Jung wrote: On 14.06.2014 10:23, Kaspar Brand wrote: On 13.06.2014 16:55, Rainer Jung wrote: Now since a long time most clients do no longer rely on the server caching the sessions. Instead they use TLS session resumption (RFC 5077). without server-side state/stateless is actually the important term from this RFC (session resumption is a standard protocol feature). Currently mod_ssl does not provide a way to control the time how long such a ticket may be used by the client. As far as I can see, there is no specific API in OpenSSL for that, but there is a general API allowing to set a session timeout that is checked whenever a session is reconstructed. What OpenSSL function do you have in mind? SSL_SESSION_set_timeout? I was hoping SSL_CTX_set_timeout() would do the trick. AFAICT, t1_lib.c:tls_decrypt_ticket simply restores the (relative) timeout for the SSL_SESSION, which is set to 5 minutes by default... but if I'm understanding correctly, you are concerned about clients reusing old tickets, is that correct? (If so, then I guess there's currently no other way than switching to a new ticket encryption key, see also [1]). Yes that's my concern. I will give SSL_CTX_set_timeout() a try over the weekend. SSL_CTX_set_timeout() seems to work pretty well. I tested with Firefox 30 as client using TLS 1.2 and verifying that the server side cache was not used. As soon as the new timeout is over (delta to the creation time of the session), resumption fails and a new session is created. In addition to the usual directive management lines, the patch should be as simple as Index: modules/ssl/ssl_engine_init.c === --- modules/ssl/ssl_engine_init.c (revision 1593916) +++ modules/ssl/ssl_engine_init.c (working copy) @@ -1365,6 +1365,8 @@ } #endif +SSL_CTX_set_timeout(sc-server-ssl_ctx, sc-server-session_timeout); + return APR_SUCCESS; } where sc-server-session_timeout is the new configuration item (if we do not stick to the existing cache timeout). Kaspar [1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201308.mbox/%3C2013082727.GA7331%40redhat.com%3E or https://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3C52248C40.7070206%40opensslfoundation.com%3E Rainer
Re: svn commit: r1602523 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c proxy_util.c
On Fri, Jun 13, 2014 at 5:10 PM, j...@apache.org wrote: Allow for magic scheme auto which makes the scheme of the backend worker match whatever the scheme of the incoming request was... For example: ProxyPass / auto://foo.example.com/ If the incoming request is http:.../lala then the resultant will be http://foo.example.com/lala If it's wws:.../lolo then we'd send wws://foo.example.com/lolo Does this work for websockets? Isn't the scheme http:// + Upgrade for websockets? I thought auto would mean the handlers would second-guess the scheme, but if we replace it in proxy_util.c they cannot do that anymore. -- Eric Covener cove...@gmail.com
Re: svn commit: r1602523 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c proxy_util.c
On Jun 14, 2014, at 7:06 AM, Eric Covener cove...@gmail.com wrote: On Fri, Jun 13, 2014 at 5:10 PM, j...@apache.org wrote: Allow for magic scheme auto which makes the scheme of the backend worker match whatever the scheme of the incoming request was... For example: ProxyPass / auto://foo.example.com/ If the incoming request is http:.../lala then the resultant will be http://foo.example.com/lala If it's wws:.../lolo then we'd send wws://foo.example.com/lolo Does this work for websockets? Isn't the scheme http:// + Upgrade for websockets? I thought auto would mean the handlers would second-guess the scheme, but if we replace it in proxy_util.c they cannot do that anymore. I thought the idea/issue was that we wanted, for example, an incoming http request to be handled by the http proxy scheme handler and if it was ws, to be handled by the ws scheme handler. This was not possible with the normal setup ProxyPass / http://foo.bar/ since all requests in this case would go to the http scheme handler (no matter what the incoming scheme was) as well as ProxyPass / ws://foo.bar/ Which would always go websockets, whether we wanted to or not. In other words, the incoming scheme determined the scheme we use on the backend, instead of it being hard-coded in the ProxyPass command. Not sure if I misunderstood or not :/
Re: svn commit: r1602523 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c proxy_util.c
On Sat, Jun 14, 2014 at 3:29 PM, Jim Jagielski j...@jagunet.com wrote: On Jun 14, 2014, at 7:06 AM, Eric Covener cove...@gmail.com wrote: On Fri, Jun 13, 2014 at 5:10 PM, j...@apache.org wrote: Allow for magic scheme auto which makes the scheme of the backend worker match whatever the scheme of the incoming request was... For example: ProxyPass / auto://foo.example.com/ If the incoming request is http:.../lala then the resultant will be http://foo.example.com/lala If it's wws:.../lolo then we'd send wws://foo.example.com/lolo Does this work for websockets? Isn't the scheme http:// + Upgrade for websockets? I thought auto would mean the handlers would second-guess the scheme, but if we replace it in proxy_util.c they cannot do that anymore. I thought the idea/issue was that we wanted, for example, an incoming http request to be handled by the http proxy scheme handler and if it was ws, to be handled by the ws scheme handler. This was not possible with the normal setup But a websockets request is a http scheme (really no explicit scheme) + an upgrade header. GET /chat HTTP/1.1 Connection: Upgrade Upgrade: websocket Host: 127.0.0.1:8080 Origin: 127.0.0.1:8080 Sec-WebSocket-Version: 13 Sec-WebSocket-Key: MTMtMTQwMjc3NDQxMzE0Ng== HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: fVFPYVP6z6n4b2wNyVnJz25W2Os= .c..d
Re: svn commit: r1602523 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c proxy_util.c
I thought RFC 6455 specifies ws and wss... On Jun 14, 2014, at 3:36 PM, Eric Covener cove...@gmail.com wrote: On Sat, Jun 14, 2014 at 3:29 PM, Jim Jagielski j...@jagunet.com wrote: On Jun 14, 2014, at 7:06 AM, Eric Covener cove...@gmail.com wrote: On Fri, Jun 13, 2014 at 5:10 PM, j...@apache.org wrote: Allow for magic scheme auto which makes the scheme of the backend worker match whatever the scheme of the incoming request was... For example: ProxyPass / auto://foo.example.com/ If the incoming request is http:.../lala then the resultant will be http://foo.example.com/lala If it's wws:.../lolo then we'd send wws://foo.example.com/lolo Does this work for websockets? Isn't the scheme http:// + Upgrade for websockets? I thought auto would mean the handlers would second-guess the scheme, but if we replace it in proxy_util.c they cannot do that anymore. I thought the idea/issue was that we wanted, for example, an incoming http request to be handled by the http proxy scheme handler and if it was ws, to be handled by the ws scheme handler. This was not possible with the normal setup But a websockets request is a http scheme (really no explicit scheme) + an upgrade header. GET /chat HTTP/1.1 Connection: Upgrade Upgrade: websocket Host: 127.0.0.1:8080 Origin: 127.0.0.1:8080 Sec-WebSocket-Version: 13 Sec-WebSocket-Key: MTMtMTQwMjc3NDQxMzE0Ng== HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: fVFPYVP6z6n4b2wNyVnJz25W2Os= .c..d
Re: svn commit: r1602523 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c proxy_util.c
On Sat, Jun 14, 2014 at 6:02 PM, Jim Jagielski j...@jagunet.com wrote: I thought RFC 6455 specifies ws and wss... It doesn't go on the wire. Once a connection to the server has been established (including a connection via a proxy or over a TLS-encrypted tunnel), the client MUST send an opening handshake to the server. The handshake consists of an HTTP Upgrade request, along with a list of required and optional header fields. The requirements for this handshake are as follows. 1. The handshake MUST be a valid HTTP request as specified by [RFC2616]. 2. The method of the request MUST be GET, and the HTTP version MUST be at least 1.1. For example, if the WebSocket URI is ws://example.com/chat, the first line sent should be GET /chat HTTP/1.1. -- Eric Covener cove...@gmail.com
