Help understanding server certificates
Community Forums/General Help/Help understanding server certificates
| ||
| Hiya all, I'm looking to pick a few brains if possible as I'm venturing into the world of remote networking and would like to understand the guts of how server certification works for ssl. Does anyone know how the server certification side of things works please, for the server and the client? I've been fumbling around on tons of google results to no avail. Would anyone be kind enough to walk me through it? as I can't seem to grasp it. Thanks! |
| ||
| Hi, here's the theory . TSL-protocol is the modern day SSL. Description Client-server applications use the TLS protocol to communicate across a network in a way designed to prevent eavesdropping and tampering. Since protocols can operate either with or without TLS (or SSL), it is necessary for the client to indicate to the server the setup of a TLS connection. There are two main ways of achieving this. One option is to use a different port number for TLS connections (for example, port 443 for HTTPS). The other is for the client to use a protocol-specific mechanism (for example, STARTTLS for mail and news protocols) to request that the server switch the connection to TLS. Once the client and server have agreed to use TLS, they negotiate a stateful connection by using a handshaking procedure.[4] During this handshake, the client and server agree on various parameters used to establish the connection's security: * The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and presents a list of supported cipher suites (ciphers and hash functions). * From this list, the server picks a cipher and hash function that it also supports and notifies the client of the decision. * The server usually then sends back its identification in the form of a digital certificate. The certificate contains the server name, the trusted certificate authority (CA) and the server's public encryption key. * The client confirms the validity of the certificate before proceeding. * To generate the session keys used for the secure connection, the client either: - encrypts a random number with the server's public key and sends the result to the server (which only the server should be able to decrypt with its private key); both parties then use the random number to generate a unique session key for subsequent encryption and decryption of data during the session - uses Diffie-Hellman key exchange to securely generate a random and unique session key for encryption and decryption that has the additional property of forward secrecy: if the server's private key is disclosed in future, it cannot be used to decrypt the current session, even if the session is intercepted and recorded by a third party. This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the session key until the connection closes. If any one of the above steps fail, the TLS handshake fails, and the connection is not created. TLS and SSL are defined as 'operating over some reliable transport layer', which places them as application layer protocols in the TCP/IP reference model and as presentation layer protocols in the OSI model. The protocols use a handshake with an asymmetric cipher to establish cipher settings and a shared key for a session; the rest of the communication is encrypted using a symmetric cipher and the session key. Any questions ? :-) Okey, I'll admit that I haven't done this in practise. -Henri |
| ||
| Hi Henri, Excellent... thanks! So my 'laymans terms' of it would go like this... 1. Client sends some kind of 'hiya' message to the server. 2. Server sends back the certificate which has some information about the server and the certificate, and also a public key. 3. Client verifies the certificate. How do you verify the certificate? and to know how to still trust the certificate? What stops me creating my own? 4. Client accepts the cert as valid, creates a 'session encrypt key', stores the key as the message and encrypts the new message using the public key it was given. This message can only be decrypted using another key - a private key that only the server has/knows. 5. Server uses the private key to decrypt the message. Now client and server have a 'session key' that only those 2 know. 6. Communication is now encrypted and decrypted using the session key. Unless I'm wrong ( more than likely :D ) then there's just one question in there at (3). How/what methods do we use to check the validity of the certificate and to trust it. Thanks again! |
| ||
| The certificate is issued by a certificate authority, and you can 'phone home' to them to check if it has been revoked. You can also use a self-signed certificate, but while those use equal encryption, they are less secure since you can't validate *who* you are talking to, just that a 3rd party is unlikely to be able to decypher your communications with them. (Most modern webbrowsers will throw a warning message when you're connected to a server with a self-signed certificate, although the communications are encrypted) |
| ||
| Thats great xlsior, thanks. Regarding the self-signed certificate, what's the difference between one that is signed by a CA or signed by yourself. How do you know the difference? For eg if the certificate is signed by 'someone' then how do you know that 'someone' is trustworthy? Is there like a central repository or similar? |
| ||
| After some more digging around, it turns out that CAs can be installed along side the client software for initial quick validation, or as xlsior says, you can also 'phone home' to the CA to check for revocation. You can also follow the issuing path up the chain of whoever has signed the certificate, all the way back to the original CA. Interesting stuff. Thanks Henri and xlsior! |
| ||
| I'm not that familiar but a friend told me that there's a grade and checker on how you setup your certificate. Where of course A+ is the top and some of this can be checked client side like chrome. Yes, the chain order and encryption is also critical on how your SSL info will show up in client and CA validation sites like https://www.ssllabs.com/ssltest/ Self signed is not bad but it is better to buy those authorized like verisign or komodo. |
| ||
| Hiya RustyKristi, Yes, there are some APIs that allow to check the validity using the signature that's also a part of the certificate. Pretty cool stuff, I find it quite interesting. |
| ||
| Self signed is not bad but it is better to buy those authorized like verisign or komodo. Or I recommend free certificates from https://letsencrypt.org/ |
| ||
| Yeah I was told about that it is still in beta and has some limitations (wildcards, etc) vs current CAs, not recommended for production. https://www.thesslstore.com/blog/what-is-lets-encrypt-what-should-we-make-of-it/ https://www.cybersecureasia.com/blog/lets-encrypt-vs-other-certificate-authorities-cas |
| ||
| For eg if the certificate is signed by 'someone' then how do you know that 'someone' is trustworthy? Is there like a central repository or similar In the case of webbrowsers and operating systems, its' the browser/OS vendor that pre-decided that some organizations (thawte, verisign, etc.) are trustworthy. Some cert issuers are trusted by some browser vendors but not all, so certs signed by them are less desirable than ones trusted by everyone.. But in the end it's pretty much a racket that revolves around trust. |
   |