On 07/17/2014 09:35 AM, Guus Sliepen wrote:
- I am not sure what the thread model for SPTPS is when compared with the
legacy protocol. SPTPS is vastly more complex than the legacy protocol (it
adds a whole new handshake mechanism), and it's not clear to me why it needs
to be that complicated. According to the Security page, the weakness of the
legacy protocol are "Predictable IV" and "Truncated MAC". I'm guessing SPTPS
is not designed solely to address these (relatively simple) issues.
SPTPS itself is actually not much more complicated than the legacy
protocol. It indeed fixes the weaknesses in the legacy protocol, and
it's actually based on TLS 1.2 but with cipher suite negotiation and
public key exchange removed, instead using a fixed cipher suite with the
PFS property, and always assuming both sides have each other's public
key. The goal is to implement the best current practices.
I'm not sure how PFS is an improvement in that regard, considering the
legacy protocol used ephemeral keys. There is no way to decrypt a legacy
protocol packet without knowing the ephemeral key, and the only way to
know the ephemeral key is to decrypt the metaconnection messages, so the
only place where PFS is needed is on the metaconnections.
- The way SPTPS is currently implemented in tinc, sending packets over TCP
is extremely inefficient because instead of using PACKET messages like the
legacy protocol does, it encapsulates the packet in a REQ_KEY message (for
backwards compatibility reasons, I guess). The problem is, the packet
contents are encoded using... base64. Now, I know that TCP over TCP is not
supposed to be very efficient in the first place, but a 40% encoding
overhead seems excessive to say the least. More generally, it's not clear to
me why SPTPS even needs to be used to send packets over metaconnections
which are supposed to be trusted.
It's only using those REQ_KEY messages when communicating via
intermediate nodes. The reason is that this allows for networks with
both 1.0.x and 1.1 nodes. Now, it's true that it still uses the REQ_KEY
messages when the intermediate nodes are version 1.1, but that is
something to be fixed before 1.1.0 is released.
I might end up implementing the 1.1-specific messages myself, if I have
some time and you don't mind. I guess it's as simple as adding new
senders/handlers and make them fall back to REQ_KEY if the other side's
version is pre 1.1.
Another performance issue with SPTPS over TCP is that it requires an
handshake (which adds to initial communication latency), while the
legacy PACKET mechanism doesn't.
A big difference is that in the legacy protocol, the PACKET messages are
encrypted hop-by-hop, while with SPTPS the packets are encrypted
end-to-end. That requires the extra handshake.
I get that, but in practice it's not clear how that improves security in
any way. In the current state, if you gain control over a node in the
middle, you're screwed anyway, even with SPTPS, because the compromised
node can easily force you to send your data to it (there are multiple
ways to do that I guess - messing with ADD_SUBNET messages sounds like
the most obvious one). In fact, if you're not using StrictSubnets the
compromise of *any* node results in complete compromise of the entire
network (again by sending ADD_SUBNET). I fail to see how SPTPS prevents
that.
--
Etienne Dechamps
_______________________________________________
tinc mailing list
[email protected]
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
