[ejabberd] [Operators] SSL certificates / private CAs / CACert issue

Peter Viskup skupko.sk at gmail.com
Mon Dec 17 03:13:40 MSK 2012


On 12/16/2012 11:27 PM, Claudiu Curcă wrote:
> From: operators-bounces at xmpp.org [mailto:operators-bounces at xmpp.org] On Behalf Of Peter Viskup
> Sent: duminică, 16 decembrie 2012 23:11
> To: operators at xmpp.org
> Subject: Re: [Operators] SSL certificates / private CAs / CACert issue
>
>> On 12/16/2012 10:55 PM, Claudiu Curcă wrote:
>>> From: operators-bounces at xmpp.org [mailto:operators-bounces at xmpp.org]
>>> On Behalf Of Jonas Wielicki
>>> Sent: duminică, 16 decembrie 2012 22:47
>>> To: operators at 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

I do understand the role of SSL and CAs well.
Let me share some words of one of the CACerts people (from the mailing 
thread I post in the beginning):
"One of the problems with CAcert: They sign certificates without any
  assurance of the issuer - the same, what StartCom does for class 1
  certificates, but StartCom is usually trusted by all major web browsers.
  If CAcert would offer certificate signing *only* for assured members,
  this would already improve security and trustworthyness, since then you
  can be sure, that a CAcert signed certificate is issued by a *known*
  person and not just by someone who has control over the mail server of a
  domain."

I do understand that list of trusted CAs could lead to "higher" 
security, but if we (XMPP operators) do accept CACert or StartCom then 
there could be no issue with accepting other CAs. What rules were 
followed by accepting these CAs?

The other case is:
you told I am ignorant because I do not follow some standard security 
advises and using our own CA for SSL/TLS on our public services. I fully 
agree with the security standard and best-practices, but question is - 
how many servers do use certificates which are not signed by trusted CA 
in XMPP (or SMTP) world. And if the number is higher than 
1-10-20-40-100-1000-Idon'tknowhowmany - aren't you the ignorant of the 
reality?
This is the reason of the discussion - recognize how many servers are 
using such certificates and/or certificates of CACert or other 
low-cost/problematic CAs (StartCom, [compromised] 
Verisign?,[compromised] whatever-else).
...and to come with some consensus regarding this issues on the end.

Anyway the CA world in general is in crisis and there are many voices 
calling for something which will solve all SPOFs in this design. This is 
another grey point on the CA design which should be taken in mind.

These are links to both threads:
[1] ejabberd 
http://lists.jabber.ru/pipermail/ejabberd/2012-December/007894.html
[2] XMPP operators 
http://mail.jabber.org/pipermail/operators/2012-December/001528.html

--
Peter Viskup



More information about the ejabberd mailing list