4

I was wondering if it is possible to make a new protocol which sits on top of TCP/IP and encrypts the packet which is going to be sent. One of the issues I can see is the metadata being available where anyone snooping such as an ISP could see who you are communicating with but the data part of the packet could be encrypted.

Do you think it is possible to to have a protocol at low level which sits on top of TCP/IP which could solve wire tapping entirely? Making the internet an encrypted pool of connections where no one could see what anyone is doing?

Improve this question
3
  • Why would something on top of TCP resolve wire tapping entirely?
    – Arminius
    Commented Mar 28, 2017 at 11:41
  • This is what Tor is doing. It's building an overlay network on top of TCP/IP, where the destination IPs have no meaning (the IP you're connecting to is just a random peer in the pool and not the actual recipient of your communications).
    – André Borie
    Commented Mar 28, 2017 at 12:53
  • you are contradicting yourself, first you want to put something 'on top' of the TCP/IP stack (e.a. high(er) level) than you are talking about a low level protocol. I suggest you take a look at what the OSI model actually is. and yes there are multiple solutions to add encryption to any level of the OSI model. This means your not limited to 'the top layer' but in fact could use any layer (although the physical layer can be quite hard to actually use) VPN's and TLS are examples of systems you could use for this.
    – LvB
    Commented Mar 28, 2017 at 14:17

3 Answers 3

Reset to default
5

What you're asking already exists, and you're already using it.

SSL/TLS can be used as a wrapper around TCP/IP.

As you've pointed out, it won't hide who you're communicating with or when. But it hides the information that you're sending, and has some protection against man-in-the-middle attacks.

But, you'll never solve wiretapping entirely. There will always be flaws in the implementation, or keyloggers, or other ways to get at the information users are sending.

Improve this answer
4
  • 3
    I find "SSL/TLS is a wrapper around TCP/IP." misleading. You can use it to wrap TCP, but that's not even the most common use case.
    – Arminius
    Commented Mar 28, 2017 at 11:36
  • @Arminius Updated the answer. Maybe I'm lacking coffee, but I'm trying to think of a usage of SSL/TLS where it's not used as a wrapper around TCP/IP?
    – S.L. Barth is on codidact.com
    Commented Mar 28, 2017 at 11:45
  • A wrapper around HTTP? Maybe we have a different conception about of who is "wrapping" what.
    – Arminius
    Commented Mar 28, 2017 at 11:49
  • @Arminius I guess we do. IIRC my first introductory text to SSL/TLS put it between the Transport Layer and the Session Layer of the OSI model. From a software developer's perspective, it's a wrapper (Decorator) around the Transport Layer.
    – S.L. Barth is on codidact.com
    Commented Mar 28, 2017 at 11:54
4

You're probably looking for IPsec.

IPsec is a protocol framework that provides internet layer end-to-end security which means that it can be used to encrypt your TCP/IP packets and thereby also secures any higher level traffic (HTTP, FTP, etc.).

SSL/TLS on the other hand just encrypts traffic on the application layer, meaning that a possible eavesdropper can still observe how client and server negotiate the connection and eventually capture leaking meta data (e.g. which domain you're visiting, due to SNI).

Improve this answer
1
  • While IPSec is fine for end-to-end encryption could the Web really run strictly through IPSec? I suppose IPv6 initially required IPSec, and it could be possible.
    – RoraΖ
    Commented Mar 28, 2017 at 13:38
0

Yes, you can encrypt the traffic on the OSI application layer. This is the means by which E2E message exchange works. Lots of IM apps work like this, WhatsApp, telegram, signal, etc. The utility is debatable, as lower-level cryptography is much more battle-tested and commonly implemented, but it can be done right with some effort.

It offers some additional protection against device interception; cookies, browser history, and stored keys for example. If using SSL alone, that protection is invisible to the normal client-side browser view, whereas the breadcrumbs left behind by an E2E app can be less revealing.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .