I’m analyzing rclone transfers with Wireshark. I noticed this cipher suite order in the client hello:
Cipher Suites (16 suites)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Is there any reason for this particular order? I see some issues:
- 3DES is considered unsafe these days;
- The order does not match the recommended order of Ivan Ristic (of Qualys SSLtest fame): https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices
Are you testing the webdav client or the webdav server?
Which version of rclone are you using, and more importantly which version of go was it compiled with?
Have you tried the latest beta?
The cipher suite list is what the client supports.
onno$ Applications/rclone --version
- os/arch: darwin/amd64
- go version: go1.9.2
I’ll test the latest beta.
With today’s latest beta for OSX I get the same client hello cipher list.
By default the go TLS implementation will try to be reasonably backwards compatible - that is why you see 3DES in that list, but only at the end.
It is possible to configure the cipher suites, and also the minimum TLS level but I don’t allow that in rclone yet.
You’d have to ask Andrew Gerrand and the go team about that. I’d start by asking in one of these forums.
Thanks! I’ll “have a go” at one of the forums you suggested.
As for 3DES, I found a relevant discussion here: https://github.com/golang/go/issues/21144
There, Adam Langley seems to think it’s too early to disable 3DES by default:
I would prefer to disable 3DES by default. That’s simple and clear. However, 3DES is what IE on Windows XP is clinging onto and I suspect there is a constituency of Go users who care about that. At some point the balance will shift and they’ll have to explicitly enable 3DES rather than the other set explicitly disabling it. I don’t know whether 1.10 is the point where that happens.
This applies to configuring servers though. It may make more sense to disable 3DES in a client sooner. If that would break things, there’s clearly a webmaster/admin that has been sleeping. What do you think?
Yes it should really be configurable what ciphers rclone uses for server and client, and also which TLS levels it accepts.
You can make a new issue on github about that if you like! Even better make a new issue then send a pull request