Unsolved Encryption: what's the difference between VPN, TLS, and S/MIME?

---

In the A+ episode on Mobile OS Connectivity part 2, Wes talks about S/MIME for the encryption of emails. I don't understand for example why we would need S/MIME if we connect to gmail.com in our browser with an HTTPS connection. At this point, if we already use HTTPS to connect to the website, I suppose we don't need S/MIME since the connection is already encrypted, right? Is S/MIME used only when we use email clients such as Outlook to connect to email servers?

I have the same doubt about VPNs and HTTPS. If we go to an HTTPS website, why would we use a VPN to encrypt the connection. From what I understand the difference lies in the fact that VPNs encrypt the communication in transit between the end points. But why do we use HTTPS then if it does not encrypt the communication in transit? If I am wrong and both mechanisms encrypt the communication in transit, then what is the difference between a VPN and HTTPS?

Hey @Thomas-Pondant great question, I think I am going to put this into a multipart answer. First HTTPS vs. S/MIME:

• HTTPS allows a user to secure the communication between the web browser and a website (such as gmail).
• HTTPS does not ensure that the email itself is encrypted ONLY the communication between the browser and the website.
• HTTPS secures the communication and email only while it is in transit between the client and server.
• HTTPS does not secure the email while at rest (ie. downloaded to a mobile device or laptop), S/MIME encrypts the message at rest.
• HTTPS will not secure the email when being forwarded between other email servers.
  For instance if you connect to a server via HTTPS and send an IMAP email.
  • The web browser communication is secure, however what happens to the email as it gets passed through the fabric of the internet? HTTPS is no longer there to help us protect that email while it is “in the wild”
  • Has the email been modified since it left the secure communication channel of HTTPS? We cannot be sure, S/MIME to the rescue with digital signatures and now we can validate the integrity of the email.
• Remember that enterprise email will most likely NOT be using Gmail, yMail, Outlook.com but more enterprise level versions.

I hope this helps, next up will be VPNs and TLS.

Hopefully that helps with HTTPS and S/MIME, now on to TLS:

1. When we reference HTTPS today, we commonly say HTTP over SSL, but this is just because that term is widely popular and the most recognized when referring to HTTPS. In reality when you by an "SSL" certificate from say Symantec, GoDaddy, Verisign you are actually purchasing a TLS certificate. For example when you browse to https://www.msn.com you will see the "https" designation in the URL, so one would think "this is SSL'" but in the screenshot you can see HTTPS is being implemented via TLS 1.2 (SSL versions went to SSL 3.0, see below):
   

2. The versions of SSL/TLS are

• SSL
  • SSL1.0
  • SSL2.0
  • SSL3.0
• TLS
  • TLS 1.0
  • TLS 1.1
  • TLS 1.2
  • TLS 1.3 (Draft or No official IETF RFC as of yet)

So keep in mind that with modern websites using HTTPS, it will be implemented with TLS.

I hope this helps

Next up is VPNs vs. HTTPS

Thank you for your great answers Wes!

The TLS part I understand, but I'm not sure I do regarding HTTPS and emails. If I take again two of your bullet points:

• HTTPS secures the communication and email only while it is in transit between the client and server.

• HTTPS does not ensure that the email itself is encrypted ONLY the communication between the browser and the website.

In the first one, you say that HTTPS secures the email in transit. While in the second one, you say that the email itself isn't encrypted. If the email itself isn't encrypted, what does it mean when you say HTTPS secures the email in transit? In what is HTTPS useful when it cannot even encrypt the email I'm sending? Wasn't that the first point of using HTTPS in the first place? If it doesn't encrypt the email, what does it do really? Does it encrypt things like metadata (IP addresses, HTTP headers, ...)?

Note: I did not see your answer regarding VPNs, did you manage to publish it?

@thomas-pondant,

Remember that data has two "states" per se. It's either at rest or it's in transit. The data itself has no inherent encryption properties itself. So security must be added. If you're storing the data, the data is at rest, to protect data at rest we must encrypt the data using an encryption algorithm. Once you choose to move or change the data, encrypted data cannot be used. It must be decrypted, modified, then re-encrypted again. These types of encryption are symmetric algorithms e.g. AES, 3DES

So the email itself has no encryption on it while it "moves" (in transit), we provide a different type of algorithmic process to do so. It does this using asymmetric algorithms, this is a much more complex process.

I'll wait on Wes for his part 3!

Hey Thomas,

I didn't forget about you! I have been out of the office for a bit. The last one we have to talk about is VPNs and TLS. When we think about HTTPS remember that this protocol encrypts the communication between a web browser and a server.

So take for instances a quick little diagram:

In this diagram we have User01 needs to access a public website, so how to we make it to where a user traversing a public network can connect to our company's website in a secure manner that protects the confidentiality, integrity and availability of the communication, we implement HTTPS which uses the security layer today of TLS.

Note the DMZ here, the first (external) firewall allows for public access to our company's internal resources which in this case is the company website. So what does this do for us?

What does this do?

1 - Allows access to our internal resources
2 - Does not expose our internal network to the outside world when accessing the company website
3 - Allows the customer confidentiality of the communication - via HTTPS-based encryption
4 - Allows for integrity of the communication as there is a certificate exchange/validation of the web server.
5 - Encrypts ```web-based`` communication or HTML-based communications.

What doesn't this do?

1 - Allow for access from a public network (Internet) to the internal network for authorized users
2 - Provide authentication, authorization or auditing of those external to internal connections for authorized users

So what can we do to allow authorized users or employees access to internal company resources. For example Remote User 01 works from home 3 days out of the week. This user also needs access to her work files stored in a centralized file server located on the internal company network.

We could (please do not....lol) do this

1 - Place the web application server in the DMZ
2 - Place the file server in the DMZ

As I am sure you are aware this presents a major security risk:

The web application and file server are now exposed to the public (and all the bad actors)
Authentication and authorization has to be performed, which in this case will expose the user database to the public (and all the bad actors)
Sensitive information is now exposed to the public
....and more

This is not a solution. So we need to:
1 - Keep these resources protected inside the company's internal network
2 - Implement a remote access technology that will allow for public access to internal resources that are not limited to web-based technologies such as HTTPS.
3 - Allow for the implementation of authentication, authorization and auditing.

This is where HTTPS is not a viable option because while it does allow for an encrypted communication between a web browser and a web server but lacks the other attributes we need. So insert ```VPN`` technologies.

VPNs allow us to:

1 - Connect to internal resources over existing public networks
2 - Connections appear as though the remote user is connected to the physical network
3 - Do not expose internal resources to those public networks
4 - Authentication can be performed by implementing technologies like RADIUS, TACACS+, Diameter
5 - Protect the user database from exposure to the public and bad actors
6 - Provide confidentiality to sensitive internal data through application of strong encryption.
7 - Allows for connections to and utilization of resources that do not use HTTPS (such as FTP, SSH, LDAP, SMB, NFS to name a few)

When we implement the VPN technologies we get these and more benefits. To the end user it looks like they are connected to the LAN and can access resources (not just HTTPS or web-based technologies)

And VPNs security layer can be TLS!

I hope this helps @Thomas-Pondant