SSLUseStapling: ssl handshake fails until httpd restart

[Reindl Harald]

is that by intention?

firefox refused to open our adminpanel with the error below until i 
restarted httpd - i suggest the server should retry SSLUseStapling when 
a new client connects and it has failed for whatever reason


SSLUseStapling On

An error occurred during a connection to ***:8443. The OCSP server 
suggests trying again later. (Error code: sec_error_ocsp_try_server_later)






signature.asc
Description: OpenPGP digital signature

Re: svn commit: r1692486 [1/2] - in /httpd/httpd/trunk: docs/log-message-tags/ include/ modules/http2/ modules/ssl/ server/

[Ruediger Pluem]

On 07/24/2015 02:09 PM, ic...@apache.org wrote:
> Author: icing
> Date: Fri Jul 24 12:09:44 2015
> New Revision: 1692486
> 
> URL: http://svn.apache.org/r1692486
> Log:
> new Protocols directive and core API changes to enable protocol switching on 
> HTTP Upgrade or ALPN, implemented in mod_ssl and mod_h2
> 
> Added:
> httpd/httpd/trunk/modules/http2/h2_switch.c
>   - copied, changed from r1692482, 
> httpd/httpd/trunk/modules/http2/h2_alpn.c
> httpd/httpd/trunk/modules/http2/h2_switch.h
>   - copied, changed from r1692482, 
> httpd/httpd/trunk/modules/http2/h2_alpn.h
> Removed:
> httpd/httpd/trunk/modules/http2/h2_alpn.c
> httpd/httpd/trunk/modules/http2/h2_alpn.h
> httpd/httpd/trunk/modules/http2/h2_upgrade.c
> httpd/httpd/trunk/modules/http2/h2_upgrade.h
> Modified:
> httpd/httpd/trunk/docs/log-message-tags/next-number
> httpd/httpd/trunk/include/http_core.h
> httpd/httpd/trunk/include/http_protocol.h
> httpd/httpd/trunk/modules/http2/config.m4
> httpd/httpd/trunk/modules/http2/h2_conn.c
> httpd/httpd/trunk/modules/http2/h2_ctx.c
> httpd/httpd/trunk/modules/http2/h2_ctx.h
> httpd/httpd/trunk/modules/http2/h2_from_h1.c
> httpd/httpd/trunk/modules/http2/h2_h2.c
> httpd/httpd/trunk/modules/http2/h2_h2.h
> httpd/httpd/trunk/modules/http2/h2_mplx.c
> httpd/httpd/trunk/modules/http2/h2_request.c
> httpd/httpd/trunk/modules/http2/h2_response.c
> httpd/httpd/trunk/modules/http2/h2_session.c
> httpd/httpd/trunk/modules/http2/h2_task.c
> httpd/httpd/trunk/modules/http2/h2_task_input.c
> httpd/httpd/trunk/modules/http2/h2_to_h1.c
> httpd/httpd/trunk/modules/http2/h2_util.c
> httpd/httpd/trunk/modules/http2/h2_util.h
> httpd/httpd/trunk/modules/http2/h2_version.h
> httpd/httpd/trunk/modules/http2/h2_worker.c
> httpd/httpd/trunk/modules/http2/h2_workers.c
> httpd/httpd/trunk/modules/http2/mod_h2.c
> httpd/httpd/trunk/modules/http2/mod_h2.h
> httpd/httpd/trunk/modules/ssl/mod_ssl.c
> httpd/httpd/trunk/modules/ssl/mod_ssl.h
> httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
> httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
> httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
> httpd/httpd/trunk/modules/ssl/ssl_private.h
> httpd/httpd/trunk/server/core.c
> httpd/httpd/trunk/server/protocol.c
> 

> Modified: httpd/httpd/trunk/include/http_protocol.h
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/http_protocol.h?rev=1692486=1692485=1692486=diff
> ==
> --- httpd/httpd/trunk/include/http_protocol.h (original)
> +++ httpd/httpd/trunk/include/http_protocol.h Fri Jul 24 12:09:44 2015
> @@ -700,6 +700,109 @@ AP_DECLARE_HOOK(const char *,http_scheme
>   */
>  AP_DECLARE_HOOK(apr_port_t,default_port,(const request_rec *r))
>  
> +
> +#define AP_PROTOCOL_HTTP1"http/1.1"
> +
> +/**
> + * Negotiate a possible protocol switch on the connection. The negotiation
> + * may start without any request sent, in which case the request is NULL. Or
> + * it may be triggered by the request received, e.g. through the "Upgrade"
> + * header.
> + * 
> + * The identifiers for protocols are taken from the TLS extension type ALPN:
> + * 
> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xml
> + *
> + * If no protocols are added to the proposals, the server will always 
> fallback
> + * to "http/1.1" which is the default protocol for connections that Apache
> + * handles. If the protocol selected from the proposals is the protocol
> + * already in place, no "protocol_switch" will be invoked.
> + *
> + * All hooks are run, unless one returns an error. Proposals may contain
> + * duplicates. The order in which proposals are added is usually ignored.
> + * 
> + * @param c The current connection
> + * @param r The current request or NULL
> + * @param s The server/virtual host selected
> + * @param offers a list of protocol identifiers offered by the client
> + * @param proposals the list of protocol identifiers proposed by the hooks
> + * @return OK or DECLINED
> + */
> +AP_DECLARE_HOOK(int,protocol_propose,(conn_rec *c, request_rec *r,
> +  server_rec *s,
> +  const apr_array_header_t *offers,
> +  apr_array_header_t *proposals))
> +
> +/**
> + * Perform a protocol switch on the connection. The exact requirements for
> + * that depend on the protocol in place and the one switched to. The first 
> + * protocol module to handle the switch is the last module run.
> + * 
> + * For a connection level switch (r == NULL), the handler must on return
> + * leave the conn_rec in a state suitable for processing the switched
> + * protocol, e.g. correct filters in place.
> + *
> + * For a request triggered switch (r != NULL), the protocol switch is done
> + * 

Re: svn commit: r1705236 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

[Joe Orton]

On Fri, Sep 25, 2015 at 03:54:56PM +0200, Yann Ylavic wrote:
> Couldn't we completely remove the flush from bio_filter_in_read() then?
> Or make it conditional to OpenSSL < 0.9.8m (since we support 0.9.8a at least)?

That looks correct to me, +1.

Regards, Joe

Re: Trailer and Hop-By-Hop contradition

[Graham Leggett]

On 29 Sep 2015, at 11:40 AM, Daniil Iaitskov  wrote:

> I am patching HTTP proxy module to pass trailing headers from a client to an 
> origin server.
> 
> I want it to be compatible with RFCs, and I was stumbled with 2 statements 
> from 
> them.
> 
> 1. Trailer header is hop-by-hop so it cannot be transferred to outgoing 
> connection 
> (RFC2616 13.5.1 - it's obsolete by RFC7230, RFC7231, RFC7232, 
> RFC7233, RFC7234, RFC7235, but they don't mention the ban list anymore).

You may not transfer a hop-by-hop header end to end, but you can certainly 
generate a new hop-by-hop header on the next connection that happens to have 
the same name and value as the hop-by-hop header on the earlier connection. The 
key thing is that the Trailer header and the trailers are addressing the next 
link in the chain only.

In other words, a trailer can be passed from A to B, then passed from B to C, 
but if trailers aren’t supported from C to D that’s fine too.

Regards,
Graham
—

Re: svn commit: r1705236 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

[Yann Ylavic]

On Tue, Sep 29, 2015 at 10:38 AM, Joe Orton  wrote:
> On Fri, Sep 25, 2015 at 03:54:56PM +0200, Yann Ylavic wrote:
>> Couldn't we completely remove the flush from bio_filter_in_read() then?
>> Or make it conditional to OpenSSL < 0.9.8m (since we support 0.9.8a at 
>> least)?
>
> That looks correct to me, +1.

Thanks, committed in r1705823, along with your patch (metadata
passthru) in r1705828, and finally to make a backport proposal in
r1705836.

Regards,
Yann.

h2 vs http2 discrepancies between 2.4.x and trunk

[Christophe JAILLET]

Hi,

I think that r1705257 should also be backported to 2.4.x

There are also some differences related to h2/http2 in:
   Apache-apr2.dsw
   Apache.dsw
But for these ones, 2.4.x seems to be more up to date.


There is also some references to httpd-h2.conf, httpd-h2.conf.in which 
may be better named httpd-http2.conf httpd-http2.conf.in now.

Maybe mod_h2.h could also be turned in mod_http2.h for consistency.

Content of httpd-h2.conf.in should also be tweaked. Maybe also 
httpd.conf.in.



Just my 2 cents,
CJ

Trailer and Hop-By-Hop contradition

[Daniil Iaitskov]

Hi List,

I am patching HTTP proxy module to pass trailing headers from a client to
an origin server.

I want it to be compatible with RFCs, and I was stumbled with 2 statements
from
them.

1. Trailer header is hop-by-hop so it cannot be transferred to outgoing
connection
(RFC2616 13.5.1 - it's obsolete by RFC7230, RFC7231, RFC7232,
RFC7233, RFC7234, RFC7235, but they don't mention the ban list anymore).
2. Names of trailing headers must be declared in the Trailer header
(RFC7230 4.4).

It's quite absurd, because first proxy drops Trailer and second one drops
trailing headers because they are not declared in the Trailer.

What did I miss here?
Is it possible to use trailers with proxies and obey RFCs?


-- 


Daneel Yaitskov

Re: SSLUseStapling: ssl handshake fails until httpd restart

[Jeff Trawick]

On 09/29/2015 04:20 AM, Reindl Harald wrote:

is that by intention?


The default timeout before retrying an error seems to be 10 minutes (see 
http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslstaplingerrorcachetimeout), 
which is pretty excessive.


As far as you recall about the time period before you gave up, was that 
within 10 minutes?




firefox refused to open our adminpanel with the error below until i 
restarted httpd - i suggest the server should retry SSLUseStapling 
when a new client connects and it has failed for whatever reason


SSLUseStapling On

An error occurred during a connection to ***:8443. The OCSP server 
suggests trying again later. (Error code: 
sec_error_ocsp_try_server_later)

Re: SSLUseStapling: ssl handshake fails until httpd restart

[Reindl Harald]

Am 29.09.2015 um 10:20 schrieb Reindl Harald:

is that by intention?

firefox refused to open our adminpanel with the error below until i
restarted httpd - i suggest the server should retry SSLUseStapling when
a new client connects and it has failed for whatever reason

SSLUseStapling On

An error occurred during a connection to ***:8443. The OCSP server
suggests trying again later. (Error code: sec_error_ocsp_try_server_later)


as long httpd behaves that way i suggest to re-consider if it's a good 
idea to use "SSLUseStapling On" as future default - i just disabled it 
everywhere because *any* of our https-sites using the same GoDaddy 
wildcard certificate where broken repeatly today with the same error 
message and after a "apachectl graceful" started to work again




signature.asc
Description: OpenPGP digital signature

Re: SSLUseStapling: ssl handshake fails until httpd restart

[Reindl Harald]

Am 29.09.2015 um 17:31 schrieb Jeff Trawick:

On 09/29/2015 04:20 AM, Reindl Harald wrote:

is that by intention?


The default timeout before retrying an error seems to be 10 minutes (see
http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslstaplingerrorcachetimeout),
which is pretty excessive.

As far as you recall about the time period before you gave up, was that
within 10 minutes?


i just restarted the servers and disabled stapling since all our 
servcies where unreachable (before i write the second mail 5 different 
hosts with several sites where affected)


in fact the error caching does more harm than benefits - IHMO a better 
"could not reach OCSP server or received a error from it" caching would 
be just temporary disable stapling for 10 minutes instead lead in 
connections fail even from clients which have disabled OCSP completly



firefox refused to open our adminpanel with the error below until i
restarted httpd - i suggest the server should retry SSLUseStapling
when a new client connects and it has failed for whatever reason

SSLUseStapling On

An error occurred during a connection to ***:8443. The OCSP server
suggests trying again later. (Error code:
sec_error_ocsp_try_server_later)




signature.asc
Description: OpenPGP digital signature