Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well

Xuelei Fan xuelei.fan at oracle.com
Mon Sep 17 16:51:33 UTC 2018


Hi Norman,

Please file an issue for the tracking.

Thanks,
Xuelei

On 9/17/2018 5:57 AM, Norman Maurer wrote:
> Should I open an issue somewhere to keep track of it or will you take care of it ?
> 
> Bye
> Norman
> 
> 
>> On 11. Sep 2018, at 17:01, Norman Maurer <norman.maurer at googlemail.com> wrote:
>>
>> This sounds great.
>>
>> I have no idea how many people still use X509TrustManager, sorry.
>>
>> It may be a good idea to add something to the java docs to tell people to prefer X509ExtendedTrustManager as well.
>>
>> Bye
>> Norman
>>
>>> Am 11.09.2018 um 16:44 schrieb Xuelei Fan <xuelei.fan at oracle.com>:
>>>
>>> Hi Norman,
>>>
>>>
>>> It may be doable by adding a delegation mode to public TrustManagerFactory:
>>>   TrustManagerFactory.init(X509TrustManager proxy)
>>>
>>> However, the X509ExtendedTrustManager should be recommended for now since its introducing in JDK 7.
>>>
>>> Do you know how many users are still using the X509TrustManager implementation?
>>>
>>> Thanks,
>>> Xuelei
>>>
>>>> On 9/11/2018 3:32 AM, Norman Maurer wrote:
>>>> Hi all,
>>>> Would it be possible to consider exposing SSLContextImpl#AbstractTrustManagerWrapper somehow so it would be possible to reuse it when a custom SSLEngine / SSLContextSpi is provided ?
>>>> I am asking because it provides really nice extra functionality by wrapping for X509TrustManager implementation and do extra hostname checks etc. At the moment we can not make use of this extra functionality in netty with our custom SSLEngine implementation as there is no way to access this. Which means depending on if the user use our implementation or the default implementation the behaviour if quite different when using a X509TrustManager in the sense that when using the default implementation a lot of extra checks are done.
>>>> As the extra checks done in AbstractTrustManagerWrapper is not really depending on the underlying SSLContextSpi implementation (at least as far as I was able to understand it so far) it would be nice to be able to make use of it.
>>>> Bye
>>>> Norman
> 


More information about the security-dev mailing list