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