Hi,

@ Thomas Hoffmann, Mark and Chris,
        Thanks for your suggestion.

We have done changes as per the xml configuration provided by Thomas Hoffmann 
and then verified the scenario. Now, client connection with TLS1.1 and TLS1.0 
are restricted as expected. 


                                        SSLHostConfig sslHostConfig = new 
SSLHostConfig();
                                        sslHostConfig.setInsecureRenegotiation( 
false );
                                        sslHostConfig.setCertificateFile( 
certLocation );
                                        sslHostConfig.setCertificateKeyFile( 
certKeyLocation );
                                        
sslHostConfig.setCertificateKeyPassword( certKeyPassword );
                                        if( isClientAuthreq && 
caCertificatePath != null && !caCertificatePath.isEmpty() )
                                        {
                                                
sslHostConfig.setCertificateVerification( 
CertificateVerification.REQUIRED.toString() );
                                                
sslHostConfig.setCaCertificateFile( caCertificatePath );
                                        }
                                        sslHostConfig.setProtocols( 
"+TLSv1.2,+TLSv1.3" );
                                        this.addSslHostConfig( sslHostConfig );
                                        IntrospectionUtils.setProperty( this, 
"SSLEnabled", "true" );
                                        IntrospectionUtils.setProperty( this, 
"sslImplementationName", 
"org.apache.tomcat.util.net.openssl.OpenSSLImplementation" );



Regards,
Natraj
-----Original Message-----
From: Thomas Hoffmann (Speed4Trade GmbH) 
<[email protected]> 
Sent: Tuesday, October 19, 2021 2:11 PM
To: Tomcat Users List <[email protected]>
Subject: AW: Restriction of TLS version in HTTP2 over HTTPS with OpenSSL

Hello,

I can recommend SSLScan for verifying your configuration:
https://protect2.fireeye.com/v1/url?k=b3c1d19c-ec5aebd9-b3c19107-867b36d1634c-7180cbae66c5853c&q=1&e=3a5cfd26-c400-4730-b545-682123db5c0f&u=https%3A%2F%2Fgithub.com%2Frbsec%2Fsslscan%2Freleases%2Ftag%2F2.0.10

Example configuration which I use:
<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
         
sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementation"
               maxThreads="150" minSpareThreads="25"
               URIEncoding="UTF-8" useBodyEncodingForURI="false"
               enableLookups="false" disableUploadTimeout="true"
               acceptCount="100" scheme="https" secure="true"
               SSLEnabled="true"
               compression="force" >
        <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol"  />
        <SSLHostConfig 
ciphers="ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"
                                disableSessionTickets="true"
                                honorCipherOrder="false"
                                protocols="+TLSv1.2,+TLSv1.3">
                <Certificate certificateKeyFile="../xxx.key"    
certificateFile="../xxx.pem"  type="RSA"        />
        </SSLHostConfig>
</Connector>

SSLScan reports this result:

  SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   disabled
TLSv1.1   disabled
TLSv1.2   enabled
TLSv1.3   enabled

Greetings,
Thomas

-----Ursprüngliche Nachricht-----
Von: Mark Thomas <[email protected]>
Gesendet: Dienstag, 19. Oktober 2021 10:18
An: [email protected]
Betreff: Re: Restriction of TLS version in HTTP2 over HTTPS with OpenSSL

On 19/10/2021 06:20, Natraj Thekkan wrote:
> Hi Mark or Chris,
> 
> Based on Chris statement, it has to be addressed in tomcat.

No, you has misunderstood Chris's statement. All the evidence so far points to 
user error.

Again, you need to provide the simplest, *complete* test case (i.e. the source 
code for an executable Java class that starts a Tomcat instance that listens 
for HTTP/2 connections) that responds to TLS 1.0 and 1.1 connections when 
configured not to.

> Can I raise a Bug in Bugzilla for this observation?.

No.

Mark


> 
> Regards,
> Natraj
> -----Original Message-----
> From: Christopher Schultz <[email protected]>
> Sent: Monday, October 18, 2021 10:14 PM
> To: [email protected]
> Subject: Re: Restriction of TLS version in HTTP2 over HTTPS with 
> OpenSSL
> 
> Natraj,
> 
> On 10/18/21 01:19, Natraj Thekkan wrote:
>> @Mark
>>      Thanks for your response.
>>
>> We have tested by removing that line of code, still client able to establish 
>> the connection with server using TLSv1 and TLSv1.1. Below one is configured 
>> in java.security file.
>>
>> jdk.tls.disabledAlgorithms=SSLv3,TLSv1,TLSv1.1,RC4,MD5withRSA,ADH,DH,DHE,
>>       DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
>>       include jdk.disabled.namedCurves
> 
> Note that OpenSSL will ignore the jdk.tls.disabledAlgorithms setting.
> 
> Mark (and others), maybe we should take jdk.tls.disabledAlgorithms into 
> account when configuring OpenSSL through JSSE, since a user might expect that 
> all JSSE providers will respect that setting.
> 
> -chris
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to