Cannot handshake with speed.hetzner.de
let4be opened this issue · 4 comments
Trying to download a file, but handshake fails with server chose an unconfigured cipher suite
I've modified the uTLS sources to see what cipher was selected and got:
tls: server chose an unconfigured cipher suite from the list of([4866 4867 4865 49196 49200 159 52393 52392 52394 49195 49199 158 49188 49192 107 49187 49191 103 49162 49172 57 49161 49171 51 157 156 61 60 53 47 255]): 159
error is happening here:
Line 586 in 30f5a69
(master branch)
Looks like 159 (0x9F) is not present in utlsSupportedCipherSuites
any advice?
Unfortunately FAKE_TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
(0x9F) is not a real cipher suite supported cipher suite by uTLS. Being a FAKE_
cipher means, uTLS supports advertising it in the ClientHello but will not be able to work with it.
Line 65 in 30f5a69
Would you be interested in trying to implement it? I am open to a PR, but here is a warning: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
is a weak cipher in TLS 1.2 and has been deprecated. Even if someone comes with a PR, it will not be merged into uTLS until a // Deprecated:
flag is properly added.
Just curious, is it that your server or someone else's server preferring a weak cipher? A more proper way in terms of security to handle this, instead of connecting to the server WITH the 0x009f
cipher, is to notify the admin about this vulnerability.
(Of course, unless it is you trying to break the known weak ciphers, then have fun!)
It's someone else's server I'm trying to connect to.
(Curl's clienthello)
In that case, it is super weird and vulnerable. Possibly it is running an outdated TLS server. But for now, unfortunately I'm afraid there's no proper workaround to allow you to handshake with something that uTLS does not really implement.