Difference between revisions of "Openssl"
(→SSL Terminology) |
(→SSL Terminology) |
||
| Line 18: | Line 18: | ||
SSL/TLS works with public key encryption. The server has a public and a private key. When a client connects the public key is sent and that can be used to encrypt the information so that only the server can decypher it with its public key. In reality this is only used to negotiate an additional symmetric key that is only used during the session. |
SSL/TLS works with public key encryption. The server has a public and a private key. When a client connects the public key is sent and that can be used to encrypt the information so that only the server can decypher it with its public key. In reality this is only used to negotiate an additional symmetric key that is only used during the session. |
||
| − | Now this works but there is one major weakness in this: |
+ | Now this works but there is one major weakness in this: Anyone can generate a pair of key. Even some hacker who diverted the network traffic and intercepts it. So you might think that you are on the website of your bank but in reality you are connected to somewhere else. |
| + | So there is a need to be able to decide which public key is legitimate. In SSH this is mainly solved by remembering the finger prints of the keys of your hosts. But that solution does not scale well. |
||
| − | The public key will be stored in a certificate. This certificate contains public key, the name of the server, information about the owner and the period of validity, a reference to a certificate authority that has signed this key and the digital signature of that authority. |
||
| + | |||
| + | So the public key is distributed with a so called <q>certificate</> that is signed by a trusted authority. |
||
| + | |||
| + | This certificate contains public key, the name of the server, information about the owner and the period of validity, a reference to a certificate authority that has signed this key and the digital signature of that authority. |
||
| + | |||
| + | So the client can verify which authority has signed that key. The certificates of the authorities are stored and distributed within the common browsers. Usually the certificates of the servers are not signed directly but there are some intermediate instances in between. This is to be able to better protect the original (root) certificates. |
||
== openssl == |
== openssl == |
||
Revision as of 16:55, 1 April 2020
Motivation
As we know: The traffic on the internet is constantly monitored and there are a lot of bad guys out there who want to hack into your systems. Encrypting the information is thus a must. With openssl we have a general purpose tool that helps you with all tasks regarding SSL encryption.
Here you get a quick overview of how to handle certificate with openssl.
SSL Terminology
When you build a service that is protected with SSL there are 2 options:
- Only the server has a certificate and anyone can connect, yet the traffic is encrypted.
- The Client also presents a certificate to the server and the server can allow or deny access based on that certificate.
Let's first try to understand the first case:
SSL/TLS works with public key encryption. The server has a public and a private key. When a client connects the public key is sent and that can be used to encrypt the information so that only the server can decypher it with its public key. In reality this is only used to negotiate an additional symmetric key that is only used during the session.
Now this works but there is one major weakness in this: Anyone can generate a pair of key. Even some hacker who diverted the network traffic and intercepts it. So you might think that you are on the website of your bank but in reality you are connected to somewhere else.
So there is a need to be able to decide which public key is legitimate. In SSH this is mainly solved by remembering the finger prints of the keys of your hosts. But that solution does not scale well.
So the public key is distributed with a so called certificate</> that is signed by a trusted authority.
This certificate contains public key, the name of the server, information about the owner and the period of validity, a reference to a certificate authority that has signed this key and the digital signature of that authority.
So the client can verify which authority has signed that key. The certificates of the authorities are stored and distributed within the common browsers. Usually the certificates of the servers are not signed directly but there are some intermediate instances in between. This is to be able to better protect the original (root) certificates.
