Re: SSL Certificate Question

On Sun, Feb 16, 2014 at 7:45 AM, Jasper Kips <jasper@planetkips.nl> wrote: > > Op 16 feb. 2014, om 05:26 heeft Tedd Sperling <tedd@sperling.com> het volgende > geschreven: > >> Hi gang: >> >> I wrote this Friday, but forgot to send it and don't want to wait until next Friday. >> So, if you ppls would be so kind as to enlighten me and before I shoot my mouth off and make a >> complete fool of myself, please tell me if I am wrong. >> >> I claim that a SSL Certificate is nothing more than a software instrument used by Browsers >> to alert users that the site they are visiting is indeed the site being reported -- IOW, the >> identify of the site can be trusted. >> >> I also claim that s SSL Certificate has absolutely nothing to do with actual HTTPS >> communication between the Browser and the Server. For example, I can use HTTPS communication by >> simply placing a script in a HTTPS directory or using a .htaccess directing such -- all without a >> SSL Certificate. >> >> Now, am I wrong? >> >> Thanks, >> >> tedd > > Yes, you are wrong. A SSL Certificate is NOT (repeat not) an identification of a site. If > anything, identificationwise, it is a signed statement by the provider of the certificate, that the > provider feels the Certificate details are right, and therefore the site claim to be who the > Certificate says it is, could be right. The trustworthiness of the claim that the certificate that > it belongs to the site serving it, and thereby establish its identity, is dependent of the > trustworthiness of all certificates in the chain of certificates, all the way up to the root > certificate. Thus if any certificate in the chain is compromised, the end certificate is not to be > trusted. And this happens, more often than we want. Certificate authorities get compromised, more > that you think. The most notable compromised authority was Diginotar. > > Besides the compromise, there are CA's that do not check of the person, company or > whatever, is actually representing who they claim to represent. This is common for personal > certificates. > > And, finally, there is a beast called 'self signed certificate'. These are mainly > used to ensure encryption can take place, and do not identify the server as being the server they > claim to be. > > As far as encryption goes, de HTTPS encryption is based on PKI. Therefore the server has two > certificates, the private one, which should never be served, and the public one, which always is > served. The certificate is used for the first part of the handshake for encryption. > > So, technically, you got it reversed. Although one goal of the certificate in HTTPS is > identification, it is in itself not trustworthy, although lots of times it can be trustworthy. It is > however needed to setup the encryption, between client and server in HTTPS. > > Disclaimer, the bove is a very rough, very very rough, sketch of the role of the certificates. > It is more complex than I described, but basically it is how encryption and identification work. And > my state ment that the certificatie is not an identification, is a very non nuanced statement. > > Jasper I know I know too little to add anything into this. What I do want to add is that SSL Certs are useful far beyond the Browser and [Web] Server. Perhaps more accurate is to just say client and server, as anything can be a client, not just a browser. Frequently, my web apps and other server apps require an encrypted connection with another web service, using HTTPS, which case my app is behaving as a client, but most certainly could not be called a browser. SSL Certs are useful for p.much any web client/server protocol that you may want encrypted; a good example is mail (IMAP, POP, SMTP). Jabber, IRC, and other messaging protocols use them as well.