[Bug 63368] New: TLS1.3 Client verification failures

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63368

            Bug ID: 63368
           Summary: TLS1.3 Client verification failures
           Product: Apache httpd-2
           Version: 2.4.39
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: mod_ssl
          Assignee: bugs@httpd.apache.org
          Reporter: tlhackque@yahoo.com
  Target Milestone: ---

Situation:
Website works with TLS1.2 (and below), not with TLS1.3

Core issue appears to be TLS1.3/HTTP/2's prohibition on renegotiation - now,
extending to post_handshake (client) authentication.

The httpd documentation still indicates that ths setup should work.  Users
expect it.

The use case seems fairly common: If a user has a certificate, no
username/password is required by the applications - and some protected features
are enabled based on stronger proof of identity.  Casual users don't get a
certificate.  But only one URL is published.

Working with TLS1.2 and below:
Global default: SSLVerifyClient none

Selected Locations: SSLVerifyClient require (or optional)

With TLS1.3:

Renegotiation fails.

Tried:
Global default: SSLVerifyClient optional

Selected Locations:  require ssl-verify-client

Tracing reveals: SSL Library Error: error:14268117:SSL
routines:SSL_verify_client_post_handshake:extension not received

Firefox and Chrome (at least) claim they can't support it for various reasons:
https://bugs.chromium.org/p/chromium/issues/detail?id=911653
https://github.com/httpwg/http-extensions/pull/772
https://tools.ietf.org/html/draft-davidben-http2-tls13-00

As far as I can tell, these postions/proposals mean that 'optional'
verification can't work; the applicationi would have to field two different
servers (one with 'none' and one with 'required'.  And somehow users need to be
redirected - e.g. "If you have a certificate, click here"

Not appealing to the users.  Or to the host - a seoarate host for
authentication? Modifying every application's entry page to have such a link
and add the logic/state maintenance?

With that background:

1) What is the apache/httpd position on this regression?  mod_ssl seems to have
code to enable post_handshake_auth; OpenSSL as well.  But if the clients won't
support it...

2) Short of fielding another host and modifying applications, is there anything
I can do with current configuration options to make this work?  (Sticking with
TLS1.2 is not a long-term choice...)  Bouncing connections with a redirect from
part of the URL space might work - but besides increasing connection times,
telling 1/2 the users about this and managing it is not attractive.

3) What can httpd do behind the scenes to make this work without application or
(big) configuration changes?  Perhaps internally it could generate a redirect
to an internal vhost, then pass the connection back after getting a
certificate?  Configuring a certificate for that purpose would be tolerable. 
Other possibilities>

4) If the capability really is not salvagable, at a minimum it needs to be
formally deprecated, documented, and worked-out alternatives provided -- before
TLS 1.2 is outlawed.

It would be helpful to understand the roadmap before embarking on "solutions"
to this functional regression.

Thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

[Bug 63368] TLS1.3 Client verification failures

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63368

a10-b4l@xuon.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |a10-b4l@xuon.net

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

[Bug 63368] TLS1.3 Client verification failures

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63368

Joe Orton <jo...@redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #1 from Joe Orton <jo...@redhat.com> ---
If browser vendors are choosing not to make this work by default for HTTP/1.1
as it did for TLS/1.2 that is out of our hands, but I don't think it implies we
need to deprecate the functionality in mod_ssl.

I agree it is a functional regression which will likely impede adoption of
TLS/1.3, and I'm not aware of any workaround other than using a separate vhost
for client-cert-auth-protected resources.

There is an effort to replace PHA at application layer in HTTP/2 which makes
sense technically in the long.  But that will require time and effort to
implement assume it makes it through standardization and won't benefit HTTP/1.1
users.  I assume it will require support from OpenSSL as well -
https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03

*** This bug has been marked as a duplicate of bug 62975 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org