3 ms·

I believe my method could work around middleboxes if you make an onion. Each layer of the onion could be encrypted separately. The packet going over the interne

I believe my method could work around middleboxes if you make an onion. Each layer of the onion could be encrypted separately. The packet going over the internet would just expose "host:node01". When it got to the host, the stack would attempt to unravel the next layer, find that it's TLS, use a cert matching "node01" to decrypt the payload. Then find the next layer, find that it's is HTTP, and so on. You could forward many layers over many networks with each node/service only decoding what it has a certificate (or authorization?) for, with only the final layer getting the full data payload.

zamadatix 5y ago
Encrypted layers already exist in the current stack: MACsec for Ethernet or WPA et al for Wireless or 3G/4G since day one and so on for each option in the network/interface layer, IPsec for the network layer, TLS for transport layer, and after that you're in the application layer which can choose it's encryption. The friction with getting the lower layers encrypted hasn't been lack of option to do so in the current stack it's convincing everyone to throw out their middlebox setups to allow the encrypted protocols universally. Well that and encryption is more expensive (both performance and implementation cost) so the less you can get away with the easier it is to convince people to do. If that were easy to get people to change the middleboxes then we wouldn't be in this situation in the first place. This is one of the main reasons why everything is over HTTPS these days: it was the lowest layer universally deployed net new protocol that was encrypted from day 1 and didn't have to worry about ossification as much. It's far easier to just use that as the new base transport layer and ignore the problem, doing so with new encrypted protocols over UDP when the functionality you're trying to replace in your protocol is at the TCP level.

zamadatix 5y ago

Encrypted layers already exist in the current stack: MACsec for Ethernet or WPA et al for Wireless or 3G/4G since day one and so on for each option in the network/interface layer, IPsec for the network layer, TLS for transport layer, and after that you're in the application layer which can choose it's encryption. The friction with getting the lower layers encrypted hasn't been lack of option to do so in the current stack it's convincing everyone to throw out their middlebox setups to allow the encrypted protocols universally. Well that and encryption is more expensive (both performance and implementation cost) so the less you can get away with the easier it is to convince people to do. If that were easy to get people to change the middleboxes then we wouldn't be in this situation in the first place. This is one of the main reasons why everything is over HTTPS these days: it was the lowest layer universally deployed net new protocol that was encrypted from day 1 and didn't have to worry about ossification as much. It's far easier to just use that as the new base transport layer and ignore the problem, doing so with new encrypted protocols over UDP when the functionality you're trying to replace in your protocol is at the TCP level.