peer handshake violates TLS transparency

[codedot]

Current design of the peer protocol handshake limits alternative implementations in languages other than C/C++ as described in this article. Indeed, src/ripple/overlay/README.md refers to the current implementation rather than describing the protocol:

* `Session-Signature`

    This field must be present. It contains a cryptographic token formed
    from the SHA512 hash of the shared data exchanged during SSL handshaking.
    For more details see the corresponding source code.

apparently referring to lines 31-93 in src/ripple/overlay/impl/TMHello.cpp.

OpenSSL routines SSL_get_finished and SSL_get_peer_finished are being used to access Finished messages sent over the socket which violates TLS socket transparency. These low-lever routines are only available in C/C++ for a reason.

Requesting protocol upgrade to RTXP/1.3 with Session-Signature (HTTP header) and nodeproof (the corresponding field of the Hello message in protobuf protocol) replaced by a more portable mechanism which would not be language-specific and could be implemented in other programming languages, for example using Node.js.

[JoelKatz]

Do you have any suggestions for what such a mechanism might be? The purpose of this code is to ensure that the two servers have ends of the same TLS connection to protect against attacks where someone proxies a connection between two servers and retains the ability to modify data.

Consider if server A wants to connect to server B and server B wants to connect to server A. Without some mechanism, two connections would have to be retained as whoever received the connection could not be confident that the inbound connection was in fact made by the intended peer.

[codedot]

Yes, absolutely, it was exactly these considerations that were presented in Why is it unlikely to have a complete and alternative implementation of Ripple? which I mentioned in my bug report. While the point of mutual authentication between peers is valid, the problem is that the OpenSSL routines SSL_get_finished and SSL_get_peer_finished are not available in most platforms.

The standard mechanism to ensure SSL/TLS connection is issued by trusted parties is to have keys. Node.js supports keys both for server side and client side. Why not use them to identify peers instead of reinventing the wheel by creating another pair of keys and messing with the TLS socket? At least, this would allow the rippled server to have a signed certificate, not just a key generated randomly or from a seed written in some plain text configuration file.

Still, even if having a key generated exactly by

require("crypto").createECDH("secp256k1").generateKeys("base64", "compressed")

is so important (although, I wonder why it would be?), at least consider using OpenSSL routines which are exposed in Node.js (thus likely to be exposed in other platforms).

P. S. I am sure it is not too much to hope that this time technical discussion will continue along technical issues without me receiving threats in personal messages.

[MarkusTeufelberger]

As far as I understand the issue, it is necessary (or at least desirable) to protect rippled <--> rippled TLS connections against active MITMs. They way this is currently done relies on signing messages that are hard to obtain with some TLS implementations (since in many cases the actual messages sent/received when establishing a connection are not that interesting to people who just want to create a TLS secured connection).

A different option might be to communicate node keys out of band (difficult, maybe centralized, does it really scale...?) or to introduce trusted third parties (signed certificates instead of just random raw keys).

Maybe a possible solution could be the second one, Let's Encrypt certificates are free and while it would be a hassle to buy a domain(!) just to run a server, it would be at least a second option to ensure MITM protection while enabling more diverse server implementations that don't have to be able to access protocol messages just for an initial handshake.

This might also improve clustering, currently one has to add nodes explicitly one by one in there, it would be nice to dynamically add any peer with a key signed by an internal CA for example.

[donovanhide]

This issue is over three years old :-)

https://groups.google.com/forum/#!topic/golang-nuts/ULtJi9oR7dI

This is probably the correct Internet standard to have adopted:

https://tools.ietf.org/html/rfc5929

Although beware:

https://mitls.org/pages/attacks/3SHAKE#channelbindings

[MarkusTeufelberger]

Yeah, I was wondering how rubblelabs did this. ;-)

[donovanhide]

I'm not doing any peer protocol stuff. Deleted it all when Vinnie started making undocumented changes to undocumented protocols.

Original poster is correct in saying that finished messages are esoteric and limited to OpenSSL. There was a whole interesting series of changes to Fabric along similar lines, using the more standard tls-unique:
https://jira.hyperledger.org/browse/FAB-1046?jql=text%20~%20%22tls-unique%22

[MarkusTeufelberger]

It would probably be easier to just rip this stuff out of a custom version of rippled and run a few "bridge" nodes between a reimplementation and the C++ version to keep the networks connected... but the protobuf peer protocol would still need to be reimplemented.

[codedot]

Starting from v10.0.0-nightly2018031198a14e026b, Node.js exposes SSL_get_finished and SSL_get_peer_finished from OpenSSL as tlsSocket.getFinished() and tlsSocket.getPeerFinished() in the TLS/SSL module.

[donovanhide]

openssl/openssl#5509 (comment)
Lol.

[JoelKatz]

Maybe I'm missing something, but how is using "tls-unique" any different from using the SSL_get_finished/SSL_get_peer_finished? And wouldn't using "tls-unique" also violate TLS transparency?

In any event, if this is an actual issue for anyone, they're welcome to submit a pull request. The simplest way to do it is to add support for some new form of MITM rejection while still supporting the existing scheme for a few more versions.

[donovanhide]

The difference is mostly around the logic of which side to use in which situation:

https://boringssl.googlesource.com/boringssl/+/af0e32cb84f0c9cc65b9233a3414d2562642b342/ssl/ssl_lib.c#2928

Also it has an Internet RFC that defines it.

I assumed "transparency" meant ease of implementation using a TLS library other than openssl. For instance in Go, you only ever get the side that you are meant to get:

https://golang.org/src/crypto/tls/conn.go#L1372

I'm no TLS expert, but I see that tls-unique, and by implication both finished messages, use is discouraged due to the Triple Handshake Attack:

https://www.ietf.org/mail-archive/web/tls/current/msg18263.html

I'd consider hiring an TLS expert such as @richsalz :-)