1072

General SSL (and its successor, TLS) is a protocol that operates directly on top of TCP (although there are also implementations for datagram based protocols such as UDP). This way, protocols on higher layers (such as HTTP) can be left unchanged while still providing a secure connection. Underneath the SSL layer, HTTP is identical to HTTPS. When using SSL/...


642

Since the general concept of SSL has already been covered into some other questions (e.g. this one and that one), this time I will go for details. Details are important. This answer is going to be somewhat verbose. History SSL is a protocol with a long history and several versions. First prototypes came from Netscape when they were developing the first ...


337

After the lengthy presentation of SSL in the previous answer, let's go with the fun stuff, namely: Attacks on SSL There have been many attacks on SSL, some building on implementation errors, others on true protocol weaknesses. One must remember that while SSL is one of the most attacked protocols (since it is very high profile: a successful application to ...


220

Serious certification authorities use heavy procedures. At the core, the CA key will be stored in a Hardware Security Module; but that's only part of the thing. The CA itself must be physically protected, which includes proactive and retrospective measures. Proactive measures are about preventing attacks from succeeding. For instance, the CA will be stored ...


202

Typically certificates are validated by checking the signature hierarchy; MyCert is signed by IntermediateCert which is signed by RootCert, and RootCert is listed in my computer's "certificates to trust" store. Certificate Pinning is where you ignore that whole thing, and say trust this certificate only or perhaps trust only certificates signed by this ...


117

The problem is not one of forging the signature, but of the meaning of the message. What is signed is not the message, but a hash of the message. The hash is always the same length. A message consisting of a single bit or byte can be hashed, so it can be signed, so it can be proved that your key signed it. But even if it can be proved, what does the ...


105

When a certificate is expired, its revocation status is no longer published. That is, the certificate might have been revoked long ago, but it will no longer be included in the CRL. Certificate expiration date is the cut-off date for CRL inclusion. That's the official reason why certificates expire: to keep CRL size bounded. (The unofficial reason is to ...


104

This is a subjective Cost vs Risk decision. We can't make it for you, but I can help you examine the factors involved. Cost To you: the effort of revoking the cert. If you have to do this manually, that's annoying, but if you can script it up in 10 mins and add it to your CloudFormation plays, then why not? As @Hildred points out, this also advertises that ...


102

Public Keys are designed for sharing, read access to and or publishing a public key is fine Private Keys are secret, they should only be accessible to the owner of said private key. To drive this point home, think back to every HTTPS website you have ever visited. In each case, as part of HTTPS the site gives you their public key. So not only is it safe ...


97

SNI hole You've fallen into a "SNI hole". Google will present a different certificate if there is no "Server Name Indication" given in the client's TLS handshake part. OpenSSL will not set this automatically. You have to do it manually. But all modern web clients, including CURL, should do this automatically. Hence the difference. Using SNI with OpenSSL ...


92

The keyfile will have a different header if it is password protected. Here's the top of a key without a passphrase: -----BEGIN RSA PRIVATE KEY----- MIIEogIBAAKCAQEA3qKD/4PAc6PMb1yCckTduFl5fA1OpURLR5Z+T4xY1JQt3eTM And here's the top of a key which is passphrase-protected: -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,...


88

There are one-way functions in computer science (not mathematically proven, but you will be rich and famous if you prove otherwise). These functions are easy to solve one way but hard to reverse e.g. it is easy for you to compute 569 * 757 * 911 = 392397763 in a minute or two on a piece of paper. On the other if I gave you 392397763 and asked you to find the ...


82

Firstly, often encryption is terminated at the perimeter by infrastructure which is dedicated to offloading SSL decryption. It makes it much easier to manage when you only have maintain a high degree of key security for a small (proportionally) group of servers which are dedicated to the role. The rest of your regular application servers can operate like ...


79

A word of caution: as stated in laverya's answer openssl encrypts the key in a way that (depending on your threat model) is probably not good enough any more. Of course you can add/remove a passphrase at a later time. add one (assuming it was an rsa key, else use dsa) openssl rsa -aes256 -in your.key -out your.encrypted.key mv your.encrypted.key your.key ...


71

A good question. The simplest answer is that having an expiration date ensures that you have an "audit" every so often. If there were no expiration date, and someone stopped using a certificate (and protecting the private key), no one would ever know. However, by having an expiration date you ensure that the user goes back to the company that sold them the ...


70

Summary: S/MIME and PGP both provide "secure emailing" but use distinct encodings, formats, user tools, and key distribution models. S/MIME builds over MIME and CMS. MIME is a standard way of putting arbitrary data into emails, with a "type" (an explicit indication of what the data is supposed to mean) and gazillions of encoding rules and other ...


67

tl;dr - the protocols were developed prior to MITM being perceived as a threat; the deployed infrastructure now serving billions of cell phones worldwide can't easily be changed to add cell tower validation; and governments have no interest in fixing this issue. Cell phone protocols differ from IP protocols in that they were never a peer-to-peer network of ...


66

The risks are for the client. The point of the SSL server certificate is that it is used by the client to know the server public key, with some level of guarantee that the key indeed belongs to the intended server. The guarantee comes from the CA: the CA is supposed to perform extensive verification of the requester identity before issuing the certificate. ...


64

In essence, these certificates are necessary and required for backward compatibility with XP and Server 2003. If anything was signed with these certificates, even if they're expired now, your server needs the cert trusted in order to trust the thing that the cert signed. Source: http://support.microsoft.com/kb/293781 Some certificates that are listed in ...


63

can I get a public key? It's easy using openssl rsa: $ openssl rsa -in the-private-key-from-your-question.pem -pubout writing RSA key -----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCtrKVnwse4anfX+JzM7imShXZU C+QBXQ11A5bOWwHFkXc4nTfEOr3fJjnRSU5A3IROFU/pVVNiXJNkl7qQZK5mYb8j 3NgqX8zZJG7IwLJ/Pm2sRW5Qj32C/uJum64Q/iEIsCg/mJjDLh1lylEMEuzKgTdW ...


61

None, that's why it is called a public key. It can not be used to access anything encrypted for you without solving math problems that are currently prohibitively difficult to solve. It is possible that in the future it may be possible to solve these problems and that would cause the public key to allow messages to be decoded, but there is no current known ...


60

Is it completely safe to publish an ssh public key? No, but you can do it anyway without worries (lots of people do, just look at https://sks-keyservers.net/i/ or https://pgp.mit.edu/) The reason why it's not completely safe is because if I know your public key, I can, with a neat piece of mathematics, calculate your private key. Your public key contains a ...


57

This command will show you the certificate (use -showcerts as an extra parameter if you want to see the full chain): openssl s_client -connect the.host.name:443 This will get the certificate and print out the public key: openssl s_client -connect the.host.name:443 | openssl x509 -pubkey -noout If you want to dig further, this question might be of ...


51

At the byte level, X.509 is X.509 and there is no reason why the free SSL certificates would be any better or worse than the non-free -- the price is not written in the certificate. Any certificate provider can fumble the certificate generation, regardless of whether he gets paid for it or not. The hard part of a certificate is outside of it: it is in the ...


48

I think you should segregate your environment. Only production certificates should be trusted on all your network. Dev and testing certificates should only be trusted on the computers where developers work. In a more secure environment you would not even use the same root CA for production and development environments.


47

When the private key is nothing more than a test fixture used to test some process requiring a private key and where the private key is not actually used to secure any system. In some cases it can be appropriate to commit an encrypted key. For example if the repository is public/open source but a Continuous Integration system requires access to that file - ...


47

Let's look at your fridge. Why is it connected to the Internet? It could send maintenance data to the manufacturer, connect to stores to order food for you, or tell you its contents ("fridge, how many eggs do I have?"). If you classify this data as having no impact if adversely affected, then yes, a massive infrastructure like PKI would have little value (...


45

It is not always so easy as described in the other answers. It works only with the old PEM keys. New openssh format of the keys (generated with -o option, more secure, since openssh-6.5) looks the same if you check the headers: $ head rsa_enc -----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAACmFlczI1Ni1jYmMAAAAGYmNyeXB0AAAAGAAAABCYdi7MhY $ head ...


43

That is exactly what encryption is designed to safely enable. If Bob and Alice could safely share the message without allowing attackers and eavesdroppers access to it, they would not, in fact, need encryption at all. So, yes, it is safe to allow any and everyone access to the ciphertext. You do want to authenticate it so that it cannot be tampered with ...


43

Your question is a little like this (with apologies to Tom Stoppard): "why can I stir the jam into my rice pudding, but not stir it out again?" Some mathematical operations are as easy to do backwards as forwards. For instance you can add 100 to a number as easily as subtracting 100. However, some are more difficult to reverse. For instance, if I take x and ...


Only top voted, non community-wiki answers of a minimum length are eligible