Re: mod_md v2.0.x + mod_ssl backport
> Am 09.07.2019 um 13:28 schrieb Joe Orton :
>
> On Tue, Jul 09, 2019 at 11:57:00AM +0200, Stefan Eissing wrote:
>> mod_md v2.0.x has landed in 2.4.x. This offers the ACMEv2 (RFC 8555) support
>> and offers various monitoring possibilities for admins to see what is going
>> on. But...it really needs votes for a mod_ssl related backport:
>>
>> mod_ssl: offer new hooks for modules like mod_md and remove use of mod_md's
>> optional functions.
>>
>> Without this, the new TLS challenge will not work and people still need to
>> rely on port 80. I heard from one user whose ISP is blocking incoming port
>> 80 (everything can be reasoned with "security" nowadays). So, for some, this
>> is really vital.
>>
>> I'd appreciate if some would find the time for a vote.
>
> Sorry, should have looked when you asked before...
I am even more sorry that the person originally requesting this change never
replied back.
This all makes me very sad.
> The new hooks should be in mod_ssl_openssl.h and use OpenSSL types
> properly for type-safety rather than void *, that's exactly the kind of
> thing this header was added for. Or else it should marshall everything
> through DER, not sure if that is feasible, probably less efficient.
>
> Not sure why 'struct apr_array_header_t' was used but I committed the
> trivial fix for that.
>
> The API is a bit less documented that I'd like though I know mod_ssl is
> worse than awful here, e.g. a few places not clear what the return value
> means, I have to guess/look at the implementation, this is ignored:
>
> +ssl_run_add_cert_files(s, p, pks->cert_files, pks->key_files);
>
> but this one is not:
>
>if (ssl_run_get_stapling_status(, , conn, s, x) ==
> APR_SUCCESS) {
>
> and when passing apr_array_header_t make clear it's an array of (const
> char *) because again otherwise you have to guess/read the code.
*shrugs*
Re: mod_md v2.0.x + mod_ssl backport
On Tue, Jul 09, 2019 at 11:57:00AM +0200, Stefan Eissing wrote:
> mod_md v2.0.x has landed in 2.4.x. This offers the ACMEv2 (RFC 8555) support
> and offers various monitoring possibilities for admins to see what is going
> on. But...it really needs votes for a mod_ssl related backport:
>
> mod_ssl: offer new hooks for modules like mod_md and remove use of mod_md's
> optional functions.
>
> Without this, the new TLS challenge will not work and people still need to
> rely on port 80. I heard from one user whose ISP is blocking incoming port 80
> (everything can be reasoned with "security" nowadays). So, for some, this is
> really vital.
>
> I'd appreciate if some would find the time for a vote.
Sorry, should have looked when you asked before...
The new hooks should be in mod_ssl_openssl.h and use OpenSSL types
properly for type-safety rather than void *, that's exactly the kind of
thing this header was added for. Or else it should marshall everything
through DER, not sure if that is feasible, probably less efficient.
Not sure why 'struct apr_array_header_t' was used but I committed the
trivial fix for that.
The API is a bit less documented that I'd like though I know mod_ssl is
worse than awful here, e.g. a few places not clear what the return value
means, I have to guess/look at the implementation, this is ignored:
+ssl_run_add_cert_files(s, p, pks->cert_files, pks->key_files);
but this one is not:
if (ssl_run_get_stapling_status(, , conn, s, x) ==
APR_SUCCESS) {
and when passing apr_array_header_t make clear it's an array of (const
char *) because again otherwise you have to guess/read the code.
mod_md v2.0.x + mod_ssl backport
mod_md v2.0.x has landed in 2.4.x. This offers the ACMEv2 (RFC 8555) support and offers various monitoring possibilities for admins to see what is going on. But...it really needs votes for a mod_ssl related backport: mod_ssl: offer new hooks for modules like mod_md and remove use of mod_md's optional functions. Without this, the new TLS challenge will not work and people still need to rely on port 80. I heard from one user whose ISP is blocking incoming port 80 (everything can be reasoned with "security" nowadays). So, for some, this is really vital. I'd appreciate if some would find the time for a vote. Cheers, Stefan
