[Operators] [Fwd: Re: Secure Communications Week]
Johansson Olle E
oej at edvina.net
Sat Aug 16 01:23:43 CDT 2008
15 aug 2008 kl. 23.57 skrev Peter Saint-Andre:
> Johansson Olle E wrote:
>> 15 aug 2008 kl. 20.11 skrev Peter Saint-Andre:
>>> Peter Saint-Andre wrote:
>>>> Forwarding a message sent before I fixed a Mailman restriction...
>>>> ---------- Forwarded message ----------
>>>> From: Garrett Wollman <wollman at csail.mit.edu <mailto:wollman at csail.mit.edu
>>>> To: XMPP Operators Group <operators at xmpp.org <mailto:operators at xmpp.org
>>>> Date: Fri, 15 Aug 2008 13:18:11 -0400
>>>> Subject: Re: [Operators] Secure Communications Week
>>>> <<On Fri, 15 Aug 2008 07:59:06 -0600, Peter Saint-Andre
>>>> <stpeter at stpeter.im <mailto:stpeter at stpeter.im>> said:
>>>> > How about TLS with self-signed certs + server dialback? At
>>>> least that
>>>> > would give us channel encryption.
>>>> That's no better than anonymous TLS (without certificates).
>>> This is true. I have two questions:
>>> 1. Is TLS+Dialback better than Dialback without TLS?
>> Yes. Confidentiality is always an improvement.
> Agreed. As long as people know what they're doing. :)
Well, yes. That applies to all security measures. I think it's
important to separate issues - confidentiality, identiy, authorization
Requiring TLS, but don't bothering with the rest is a first step.
Trying to solve the whole identity and authorization issue on a global
federation is something that hasn't been done yet.
>>> 2. How *should* we handle certificates that are self-signed,
>>> issued by unknown CAs, etc.?
>> There is a lot we could add in a best-practise document. Self-
>> cigned certificates doesn't
>> belong to a CA, but can still be identified with a fingerprint.
>> Postfix (e-mail server) supports
>> both fingerprints and CA-style certificate handling.
> Yes it would be good to see how this is handled in mail servers.
"Certificate fingerprint verification
Certificate fingerprint verification is available with Postfix 2.5 and
later. At this security level ("smtp_tls_security_level =
fingerprint"), no trusted certificate authorities are used or
required. The certificate trust chain, expiration date, ... are not
checked. Instead, the smtp_tls_fingerprint_cert_match parameter or the
"match" attribute in the policy table lists the valid "fingerprints"
of the remote SMTP server certificate.
If certificate fingerprints are exchanged securely, this is the
strongest, and least scalable security level. The administrator needs
to securely collect the fingerprints of the X.509 certificates of each
peer server, store them into a local file, and update this local file
whenever the peer server's public certificate changes. This may be
feasible for an SMTP "VPN" connecting a small number of branch offices
over the Internet, or for secure connections to a central mail hub. It
works poorly if the remote SMTP server is managed by a third party,
and its public certificate changes periodically without prior
coordination with the verifying site."
This is something that I think works in small, closed networks -
sneakernets - or in business relationships where you exchange the
fingerprint out of band.
A web-of-trust-model like PGP could also work and scale a bit more.
>> From reading server manuals and configurations, we could both
>> improve configurations
>> and improve documentation of this in order to make more people
>> install certificates and
>> enable encryption.
>> Authentication of domains can be assisted by a CA, or by DNS-sec.
>> There are options
>> now to store server-side SSH key fingerprints in DNS, certified by
>> DNS-sec. We could
>> certainly recommend doing the same with XMPP server certificate
>> fingerprints and have
>> that as a "lightweight" option. That won't require a global CA.
> I suppose one question is: how do you check fingerprints? Do you
> find contact information for the hostmaster and call him on the
> phone? Does XMPP traffic get queued up while you do that? Do you
> refuse the connection and flag the s2s request for action by the
> xmpp admin? And is all that really easier in the end than requesting
> a cert at xmpp.net?
Fingerprints without a secure directory is sneakernet sponsored by
Adidas. Within business relationships, fingerprints could securely be
exhanged with a high level of trust.
They have to be pre-insalled or fetched from LDAPS or something
similar. DNS-sec is one way to trust another authority - DNS - and
build upon that trust.
I don't think it's easier to use fingerprints in general, but it's a
good enough alternative in many situations. And yes, in many
situations it's easier to setup than requesting a cert at xmpp.net -
there's no reason to contact legal services to go through the
agreement and no need to install the CA certificate chain or
evaluating the CA's certificate policy. A shortcut for the engineer :-)=
> So yes, a best practices document seems like a good idea...
Can we use the wiki?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2207 bytes
Desc: not available
Url : http://mail.jabber.org/pipermail/operators/attachments/20080816/de7a2e6a/attachment.bin
More information about the Operators