Re: Unexpected result of requesting client certificate when requesting locations with different SSLVerifyClient settings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 10, 2019 at 10:48 AM Du Hao <dwaynedu@xxxxxxxxx> wrote:

I suspect there is a bug involved in the SSL client verification type changing and the re-negotiation flow. While I admit it may be a corner case but the original use case is very crucial to my current user base. I checked the Bug database and there is a similar bug except that is related to TLSv1.3. For browser compatibility, I am currently disabling TLSv1.3, although I am testing with Apache 2.4.38 and OpenSSL 1.1.1b.
I would love to hear any suggestions on an alternative configuration to support my scenario, and thank you very much in advance.

Hello Du Hau,

you probably want to abandon your current approach. With TLSv1.3, which will come to dominate and eliminate earlier TLS protocols, there is no mechanism for renegotiation. The entire site (defined using SNI, server name indication) will need to share a common handshake, the idea of only locking down https://site.example.co/protected/ gets eliminated with this protocol, and with many only TLS's which actively disable renegotiation due to the underlying potential security holes over time.





[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux