Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 592025 - gnutls does not appear to fallback from TLS 1.1 properly when server doesn't support it
gnutls does not appear to fallback from TLS 1.1 properly when server doesn't ...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gnutls (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-13 13:36 EDT by long
Modified: 2010-05-13 16:52 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-13 14:25:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description long 2010-05-13 13:36:54 EDT
Description of problem:
I'm trying to use davfs2 to connect to our webdav server at https://documents.ku.edu/.  davfs2 relies on neon which relies on gnutls.  It appears that documents.ku.edu does not support TLS 1.1 as indicated here:

[long@raptor pc]$ gnutls-cli-debug documents.ku.edu
Resolving 'documents.ku.edu'...
Connecting to '129.237.11.141:443'...
Checking for TLS 1.1 support... no
Checking fallback from TLS 1.1 to... failed
Checking for TLS 1.0 support... yes
Checking for SSL 3.0 support... yes
Checking for HTTPS server name... not checked
Checking for version rollback bug in RSA PMS... no
Checking for version rollback bug in Client Hello... no
Checking whether we need to disable TLS 1.0... N/A
Checking whether the server ignores the RSA PMS version... no
Checking whether the server can accept Hello Extensions... yes
Checking whether the server can accept cipher suites not in SSL 3.0 spec... yes
Checking whether the server can accept a bogus TLS record version in the client hello... no
Checking for certificate information... N/A
Checking for trusted CAs... N/A
Checking whether the server understands TLS closure alerts... no
Checking whether the server supports session resumption... yes
Checking for export-grade ciphersuite support... yes
Checking RSA-export ciphersuite info... N/A
Checking for anonymous authentication support... no
Checking anonymous Diffie Hellman group info... N/A
Checking for ephemeral Diffie Hellman support... no
Checking ephemeral Diffie Hellman group info... N/A
Checking for AES cipher support (TLS extension)... yes
Checking for CAMELLIA cipher support (TLS extension)... no
Checking for 3DES cipher support... yes
Checking for ARCFOUR 128 cipher support... yes
Checking for ARCFOUR 40 cipher support... yes
Checking for MD5 MAC support... yes
Checking for SHA1 MAC support... yes
Checking for ZLIB compression support (TLS extension)... no
Checking for LZO compression support (GnuTLS extension)... no
Checking for max record size (TLS extension)... no
Checking for OpenPGP authentication support (TLS extension)... no

So when I try to connect to documents.ku.edu I get:

long@raptor pc]$ gnutls-cli --priority "NORMAL" documents.ku.edu
Resolving 'documents.ku.edu'...
Connecting to '129.237.11.141:443'...
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [70]: Error in protocol version
*** Handshake has failed
GNUTLS ERROR: A TLS fatal alert has been received.

If I instead disable TLS 1.1 I can then connect:


[long@raptor pc]$ gnutls-cli --priority "NORMAL:-VERS-TLS1.1" documents.ku.edu
Resolving 'documents.ku.edu'...
Connecting to '129.237.11.141:443'...
- Certificate type: X.509
 - Got a certificate list of 1 certificates.

 - Certificate[0] info:
 # The hostname in the certificate matches 'documents.ku.edu'.
 # valid since: Tue Feb 17 18:00:00 CST 2009
 # expires at: Fri Feb 18 17:59:59 CST 2011
 # fingerprint: F1:13:06:1B:72:87:BC:AC:8C:4C:90:92:8F:CA:AF:C5
 # Subject's DN: C=US,ST=Kansas,L=Lawrence,O=University of Kansas,OU=Information Services,CN=documents.ku.edu
 # Issuer's DN: C=ZA,ST=Western Cape,L=Cape Town,O=Thawte Consulting cc,OU=Certification Services Division,CN=Thawte Premium Server CA,EMAIL=premium-server@thawte.com


- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.0
- Key Exchange: RSA
- Cipher: ARCFOUR-128
- MAC: MD5
- Compression: NULL
- Handshake was completed

- Simple Client Mode:


Version-Release number of selected component (if applicable):
gnutls-2.6.6-3.fc11.x86_64

How reproducible:
always

Steps to Reproduce:
1. gnutls-cli --priority "NORMAL" documents.ku.edu
2.
3.
  
Actual results:
[long@raptor pc]$ gnutls-cli --priority "NORMAL" documents.ku.edu
Resolving 'documents.ku.edu'...
Connecting to '129.237.11.141:443'...
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [70]: Error in protocol version
*** Handshake has failed
GNUTLS ERROR: A TLS fatal alert has been received.
[long@raptor pc]$ 


Expected results:
[long@raptor pc]$ gnutls-cli --priority "NORMAL:-VERS-TLS1.1" documents.ku.edu
Resolving 'documents.ku.edu'...
Connecting to '129.237.11.141:443'...
- Certificate type: X.509
 - Got a certificate list of 1 certificates.

 - Certificate[0] info:
 # The hostname in the certificate matches 'documents.ku.edu'.
 # valid since: Tue Feb 17 18:00:00 CST 2009
 # expires at: Fri Feb 18 17:59:59 CST 2011
 # fingerprint: F1:13:06:1B:72:87:BC:AC:8C:4C:90:92:8F:CA:AF:C5
 # Subject's DN: C=US,ST=Kansas,L=Lawrence,O=University of Kansas,OU=Information Services,CN=documents.ku.edu
 # Issuer's DN: C=ZA,ST=Western Cape,L=Cape Town,O=Thawte Consulting cc,OU=Certification Services Division,CN=Thawte Premium Server CA,EMAIL=premium-server@thawte.com


- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.0
- Key Exchange: RSA
- Cipher: ARCFOUR-128
- MAC: MD5
- Compression: NULL
- Handshake was completed

- Simple Client Mode:



Additional info:
Comment 1 Tomas Mraz 2010-05-13 14:25:45 EDT
I'm sorry, but gnutls-cli correctly falls back to TLS1.0 if the server appropriately reacts to the 1.1 version in the TLS hello. This is clearly bug on the server side.
Comment 2 Tomas Mraz 2010-05-13 14:26:56 EDT
By the way you can verify on various TLS1.0 sites that the fallback works correctly - for example gnutls-cli --priority "NORMAL" www.kernel.org
Comment 3 long 2010-05-13 16:18:13 EDT
Granted, I am not a TLS guru, but how can this be the servers fault when it clearly does not support TLS 1.1?  It even says it in the debug output:

Checking for TLS 1.1 support... no
Comment 4 long 2010-05-13 16:25:19 EDT
Ah, I think I see, you are saying my server is supposed to say that it only supports version 1.0 when 1.1 is requested.  I'll dig into that.  I take it that falling back to SSLv3 in this situation is not the right way to handle it?
Comment 5 Tomas Mraz 2010-05-13 16:52:44 EDT
No, the gnutls would have to make new connection to the server. You'll have to either fix the server or configure the client (with the priority string) so it does not use TLS1.1 version in the client TLS hello.

Note You need to log in before you can comment on or make changes to this bug.