TLS Proposal Draft #148
TLS Proposal Draft #148
Conversation
|
@bizzehdee Didn't we have on-the-wire encryption already? Though it doesn't have any standard yet (see BEP-13) |
|
@Saiv46 with it having nothing written for it, i cant really know whether it means TLS, or means an encrypted protocol, or some other method (whatever that may be)... My BEP is aimed to make this a specific implementation for a specific purpose |
|
I like this idea, but maybe the entire connection should be TLS encrypted, if the final objective is to enhance privacy and protection against MITM listeners. |
|
MITM protection requires trusted certificates, not just self-signed ones. But then the question becomes where you get that trust from (what's your CA?). The reserved bitfield is kind of limited and can't convey much information. The extension protocol (BEP 10) is widely implemented and might be a better option to convey information about TLS. A separate port may not be needed. Bittorrent clients often multiplex several things over a single port anyway and I think an incoming TLS client hello should be distinguishable from other things by matching a few bytes and then routed to a TLS library. |
|
The trust could come from the tracker, who could distribute the self signed certificates of the peers alongside their address, or directly sign them if using a private tracker. I don't say these kind of implementations would not push serious drawbacks and performance issues, but it is still something that would get a userbase, from people concerned about their privacy or their ISP/company firewall restricting bittorrent connections in general. A protocol such as this one has too many implementation considerations for it to be a simple connection upgrade, that goes during or after the handshake. Peers should be aware of another peer compatibility and certificate/CA before they connect, and trackers would be the way to go. |
Draft BEP for TLS