Feel-well Encryption?

Nowadays it appears that "encryption" became a byword for "privacy" "confidentiality" and "security". In other words, selling a product that encrypts is perceived to provide higher value and therefore justifies a higher price. Is that justified?

Let's pretend that a user figured out for himself that he would need some encryption for his data. Then an average user has a hard time to figure out if he can really trust the encryption scheme built into his applications or devices (here a discussion about self-encrypting hard disks). Even beyond figuring out whether encryption is strong enough, which is hard to answer even for experts, another key question is rarely asked: is my device actually encrypting at all?

Let's have a look at the Internet. If a user wants to know if his device is connected to the internet he can run a command like "ping 8.8.8.8". This sends a packet to an Internet address 8.8.8.8 from where it is returned to the sender. So when receiving the packet the user knows: I am connected. So far so good, but which command can we use to figure out if the ping-packet got encrypted on the way to the remote end AND got encrypted on the way back?

Today's Internet offers several options to encrypt communication. Encrypting on application level has the advantage that an application knows the encryption is running and can present the fact to the user. The lock-icon on internet browsers are an example. This is typically a little slow and a second application doesn't benefit from the encryption of a first application. So, when you have 50 tabs open in your browser it is hard to tell which one uses https and which one not. Moreover ,every tab needs to maintain a different https session.

VPNs offer another option which create an encrypted tunnel between computers. here a user has to install a vpn application that plugs itself in between the applications and the Internet. The funny thing is that if the vpn-tunnel does not work, traffic is still flowing between computers over the Internet. In that case however completely unencrypted. (that's the reason why VPNs offer a kill-switch). Also keep in mind that a VPN may not survive a restart.

Another way is to encrypt the wire which can be Hardware assisted and then runs with wire speed. However, encrypting traffic on the WLAN does not necessarily encrypt traffic on Ethernet or 4G. So, when changing the connection, encryption simply disappears. Moreover, the encryption ends at the other end of the media. Encrypting WLAN is a commonplace, but that doesn't mean anything else than the first 100m or so are encrypted and even that can be compromised.

Strange enough we see technologies like MACsec (encrypting Ethernet links between a host and a switch) and oSec (encrypting the frame that carries the Ethernet link, a new topic discussed in ITU-T) becoming more prominent now. These technologies appear to be like the Internet cousins of a self-encrypted hard disks. Even if a user trusts the implementation being good enough, how can we be sure encryption is switched-on to begin with?

Since "crypto-ping" doesn't exist, what can users do to be confident that a given resource is using encryption as expected?

The answer is simple: lower the expectation and encrypt the packets end-to-end on application level with https -- just in case. Perhaps a VPN with kill-switch could be a good option as well (it may have other privacy enhancing features too), but encrypting physical point-to-point links? There are certainly use cases for such schemes but what's in for the average user other than more configuration, more failure cases and magic hiccups?

Looks like we are getting busy to heat the planet a little more with feel-well Encryption on the wire.

my 2c