How does SSL relate to the Public Key Infrastructure?
How does SSL relate to the Public Key Infrastructure
keysssl
Related Solutions
I think it mainly depends on what you see as "the OS". If it is the kernel, my answer would be: why should it? I might be wrong, but is DNS not a part of the glibc on Linux systems, which is a thrid-party library?
If it is not about kernel or user space, nearly every OS / platform has an SSL / TLS stack, some might have more than one.
It can even be seen as an advantage. If there was no OpenSSL, you would have to adapt to the Windows, Mac and Linux ( and ... ) API. TLS not beeing part of the OS allows to write cross platform TLS applications. Just pick a TLS library, that supports your target platforms.
For me, the real problem with TLS is, that you can not simply "turn it on". Instead, you have to manage a set of trusted certificates, certificate revocation lists, self signed certificates and so on. All of these require lots of user interaction.
Sadly, security never comes for free. It is effort for programmers and inconvenience for users.
With email encryption there are two possible options (over-simplified):
- End to End encryption
- Point to Point encryption (eg TLS)
When to use each really depends on the purpose of encrypting the email. Do you want to prevent someone eavesdropping while your mail is being sent or to you want to ensure that only the intended recipient can read the email?
Point to Point
If you want to prevent someone on your network from eavesdropping than you would want to consider encrypting the transport. What this means is that the contents and the headers of the email still remain in plain-text, but the transmission between your mail software and your mail server are encrypted.
The mail server will likely store the plain-text email ready to be forwarded to the next mail sever in line for delivery. How this is done depends on the configuration of the mail server and the protocols available between it and the next mail server. It may be sent in plain text, over an un-encrypted channel.
The key to know here is that the email will be plain-text between you can all the intermediate mail servers that may handle the email.
End to End
If you want to prevent anyone other than the intended recipient than you want end-to-end encryption as you've described in your question.
This form of encryption is where you and the recipient agree on way that you will be securely communicating and use this method to perform the encryption and decryption. In your question you've described a PKI (public key infrastructure, asymmetrical encryption) way, but there is nothing preventing you from also using a pre-shared key and using symmetrical encryption.
There are a few plugins, such as PGP & GPG, that allow you to encrypt, sign, verify & decrypt email that has been sent using PKI methods.
Your scenario
You are essentially correct in your scenario.
- Compose an email in your favourite email client.
- Sign the email using your private key, this will add a digital signature block to the email.
- Retrieve the recipient's public key using a number of methods:
- Key server
- Copy on local disk
- Downloaded from a website
- etc
- Encrypt the contents of the email with the recipient's public key
- When you hit send, the contents that was encrypted is now unknown to all that the email passes through. The sender, headers, recipient and other fields will still be available to someone eavesdropping over the wire, unless point-to-point encryption is employed as well. The mail server will always have a "plain-text" copy of this information as it needs it to be able to deliver the email.
Best Answer
SSL and TLS (the newer version of the standard) is one of many transport mechanisms that allows PKI to work over the network (originally, there was X.500). I'll be using TLS for the remainder of the answer. It's outside the scope of this forum to describe PKI in full. The exact handshake is like a ballroom dance. Essentially TLS defines the framework for the server and client to identify themselves and agree on an encryption standard and key. It is this identification process that makes PKI possible through TLS.
I'm assuming you are familiar with public and private keys as well as certificates. Everything past this point assumes familiarity with those terms and concepts. Also note that TLS has several encryption and encoding standards, and not all of them support PKI. Typically, both the client and server will need signed X.509 certificates to identify themselves.
Both the server and the client have identities. In a typical online retail situation, the only entity that is really important is the server. The clients have to have confidence that they are interacting with the server they intended to. Just about all retail servers that use SSL/TLS have a certificate, which is a signed public key that advertises the signature authority.
With PKI, the server also needs to know if the client has permission to access the server. The public client certs are signed by a trust authority that is known to the server (i.e. the server has the public key for the trust authority and validates certificates against that trust cert).
The TLS wikipedia article has the exchange for the three types of handshakes (simple, client-authenticated, and session resume). The handshake that makes PKI possible is the client authenticated handshake. A really simplified version of the handshake is below:
Wikipedia has a lot less slang, but this is the basics of how PKI works over TLS. The client needs to be confident that it has the right server, and the server needs to be confident the client is who they say they are.
Important note: The effectiveness of the key exchange depends entirely on how the keys are managed. This means the policies and procedures for identifying that a client's key is in fact tied to that client is not sound, neither will the PKI be robust. Additionally, if the trust authority's private key is known by a number of people, or is unencrypted, then that trust authority cannot be trusted. The same with the client private key. TLS handles the Public Key part, but the Infrastructure is all in how you manage the keys that cooperate in this whole exchange.