From: operators-boun...@xmpp.org [mailto:operators-boun...@xmpp.org] On Behalf Of Peter Viskup Sent: duminică, 16 decembrie 2012 23:11 To: operators@xmpp.org Subject: Re: [Operators] SSL certificates / private CAs / CACert issue
> On 12/16/2012 10:55 PM, Claudiu Curcă wrote: >> From: operators-boun...@xmpp.org [mailto:operators-boun...@xmpp.org] >> On Behalf Of Jonas Wielicki >> Sent: duminică, 16 decembrie 2012 22:47 >> To: operators@xmpp.org >> Subject: Re: [Operators] SSL certificates / private CAs / CACert issue >> >>> Hi Claudiu, >>> >>>> Fair point, although I find it very hard to believe that anyone nowadays >>>> still runs an email server or Jabber server and hasn't completely turned >>>> off plaintext comms. Using plaintext comms for such communication is wrong >>>> on so many levels that I don't even want to get into such a discussion. >>> Agreed on the moral point. However, I'd like to see stats on how many >>> public services allow plaintext comm and which ratio of those even accepts >>> plaintext auth over the unencrypted channel. >>> >>> I, for myself, have enabled unencrypted communications on my XMPP service, >>> even for s2s. Why? Because the documentation of the server software I use >>> recommends it to increase interoperability. Because other servers might >>> reject my fine CACert certifiacte (although I'll look into StartSSL). >>> >>> regards, >>> Jonas W. >> Unfortunately, what you say is true and no one can say otherwise. However, >> the truth of the matter is that this situation should be improved (mainly by >> convincing the Ops to use proper certificates and discourage the use of >> unsecured connection and CAs doing a better job of ending up in Trust Store >> lists), not the other way around. If everyone started putting security ahead >> of comfort, this situation would not be as it is. >> >> Alas, this is just wishful thinking... >> >> Claudiu >Hi all, >can anyone tell me what is the difference between the certs the CACert and our >'private' CA are issuing? >I do see only one - CACert is for some unknown reason accepted by most of the >XMPP software. Once you would like to push such restrictive SSL rules you >should start with rejecting the CACert certificates and inform all XMPP >software developers that they should remove their root certs from the list of >>trusted CAs. In other case I do not see the reason why some XMPP servers >should reject any other CAs in the world. >I do appreciate work of all people in the CACert and like them, but I see this >as an grey area on this front in XMPP world. And nobody wants to touch it >because it smells. Hello Peter, It seems you do not fully understand the roles of a SSL certificate. Data encryption is only one of its roles, and this role can be achieved by any SSL certificate, even an invalid/expired one, signed by even your janitor's CA. Data is encrypted by the sender with the certificate public key and decrypted by the receiver using the certificate private key. This is why it is imperative that the private key of a certificate to be secured and not leaked. Anyone with the key can impersonate a service identity and decrypt data. Here comes in play the second role: authentication. A SSL certificate reassures a service that the peer to whom it's connecting is indeed the intended peer and not an impersonator. Because a CA will always issue certificates only to the owner of a service/server (verified via Phone/email using the WHOIS record of the domain to which the SSL certificate is issued), it means that a third party malicious entity will never be able to impersonate that specific service, unless the original certificate was leaked (see below). If you use a self-signed certificate, then a third party could create their own certificate with the same CN field in order to impersonate your service (thus creating a MITM attack). If this attacker then "proxies" the data to your server, he could eavesdrop on communications for a very long time without anyone noticing. The connecting service would never know, as it has no means of verifying the authenticity of the SSL certificate, and thus, the identity. (This method also involved DNS poisoning and its complete description is beyond the scope of this e-mail). A third role is revocation check, which is closely tied to the identity role above. Say you leak your certificate, which was issued by a trusted CA. If you contact the CA, they will revoke your old certificate and its keys and issue a new certificate with a different thumbprint. Then, the old certificate is added to a CRL (Certificate Revocation List). When a client (in s2s, a server is also considered a client) tries to connect to a server, it checks the certificate which is supplied against the CRL of the CA (OpenSSL and most SSL implementations do this by default). If the certificate is in the CRL it breaks communication since this is an impersonation attempt. This is how MITM attacks involving official CA-signed leaked certificates are foiled. All in all, these are all corner cases, but they happen on a daily basis around the world. CA-signed certificates are not there just to make the URL address "green" in the Web Browser and to make CAs filthy rich. Regarding the CACert issue, I can't say anything because I'm not following such news, but it really seems that there's some problem with getting themselves to be recognized as a trusted CA, which is sad. Hope this puts a bit of light on the usefulness of valid signed SSL certs. Claudiu
