Menu
▾
▴
fetchmail-devel
|
From: Rob M. <rob...@gm...> - 2007-08-22 21:07:26
|
I was thinking about the recent thread that Anne Wilson started about
TLS certificate problems. While there's a fairly easy way of getting
SSL certificates, there doesn't seem to be any way to use OpenSSL to
get a certificate from a TLS session.
As a generic solution it would be useful IMO if, at a high enough
verbosity (maybe -vvvv) fetchmail would display the certificate of the
remote TLS/SSL server *if that certificate can't be verified*.
Would that be reasonable, and easy to achieve? If not is there any
other tool that can be used to get the certificate for a TLS secured
POP3 or IMAP server?
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
|
From: Jakob H. <jh...@pl...> - 2007-08-22 22:56:21
|
Rob MacGregor wrote: > I was thinking about the recent thread that Anne Wilson started about > TLS certificate problems. While there's a fairly easy way of getting > SSL certificates, there doesn't seem to be any way to use OpenSSL to > get a certificate from a TLS session. You are probably looking for openssl s_client -connect your.server:pop3s (or ...:pop3 -starttls pop3) starttls works only with pop3 and smtp, though (and the smtp support is lousy...). |
|
From: Rob M. <rob...@gm...> - 2007-08-22 23:01:14
|
On 8/22/07, Jakob Hirsch <jh...@pl...> wrote:
>
> You are probably looking for
> openssl s_client -connect your.server:pop3s
> (or ...:pop3 -starttls pop3)
I just tried "openssl s_client -connect my.mail.server:pop3 -starttls
pop3" and all I get is:
connect: Connection refused
connect:errno=61
But it's a TLS capable server. Running the relevant command against
the pop3s service works fine.
> starttls works only with pop3 and smtp, though (and the smtp support is
> lousy...).
The recent thread was about an IMAP server that supported TLS, but
there was no IMAPS support, and my own test suggests that the s_client
protocol support is, well, poor. If we're going to encourage the use
of SSL/TLS (which we do by the fact that fetchmail will use TLS if
it's available) then we need to make it easy for people to import
certificates.
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
|
From: Jakob H. <jh...@pl...> - 2007-08-23 00:57:24
|
Rob MacGregor wrote: >> You are probably looking for >> openssl s_client -connect your.server:pop3s >> (or ...:pop3 -starttls pop3) > I just tried "openssl s_client -connect my.mail.server:pop3 -starttls > pop3" and all I get is: > > connect: Connection refused > connect:errno=61 I don't know anything about your server, but it works fine here: $ openssl s_client -connect koi:pop3 -starttls pop3 CONNECTED(00000003) ... +OK Dovecot ready. <...> >> starttls works only with pop3 and smtp, though (and the smtp support is >> lousy...). > The recent thread was about an IMAP server that supported TLS, but > there was no IMAPS support, and my own test suggests that the s_client > protocol support is, well, poor. If we're going to encourage the use Right, but I don't hink that fetchmail is the right tool for that. On the other hand, it's not that hard to print the certificate. But it looks like the openssl people are working on it: 0.9.8e also contains STARTTLS support for imap (and even handles smtp properly). |
|
From: Rob M. <rob...@gm...> - 2007-08-23 08:12:56
|
On 8/22/07, Jakob Hirsch <jh...@pl...> wrote:
> Rob MacGregor wrote:
>
> I don't know anything about your server, but it works fine here:
>
> $ openssl s_client -connect koi:pop3 -starttls pop3
> CONNECTED(00000003)
> ...
> +OK Dovecot ready. <...>
Ok, I've just tried it on another host and it works there, just not on
my main host - which works fine with fetchmail's TLS support.
> Right, but I don't hink that fetchmail is the right tool for that. On
> the other hand, it's not that hard to print the certificate.
From my results above it looks like the s_client functionality isn't
100%, and it's use relies on people having the very latest version for
IMAP support (from your comment below).
History on the -users mailing list suggests that we really need to
make it easy for people to solve these problems. If it's simple
enough to provide all the required information from within fetchmail
then that's got to make their lives (and by extension mine :>) easier.
If openssl's client support was better established then I'd probably
agree with you though.
> But it looks like the openssl people are working on it: 0.9.8e also
> contains STARTTLS support for imap (and even handles smtp properly).
Just tried it with one provider and it works, useful.
It does however assume that everybody is using at least 0.9.8e :) I
suppose I'm mostly concerned about the poor souls who're using RPM
based distributions. It isn't always possible to upgrade one package
without upgrading dozens of others - something people who're just
trying to get one package working may not want to/be able to do.
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
|
From: Matthias A. <mat...@gm...> - 2007-08-23 09:33:24
|
On Thu, 23 Aug 2007, Rob MacGregor wrote: > From my results above it looks like the s_client functionality isn't > 100%, and it's use relies on people having the very latest version for > IMAP support (from your comment below). Yes, older openssl s_client versions don't support as many protocols. > History on the -users mailing list suggests that we really need to > make it easy for people to solve these problems. If it's simple > enough to provide all the required information from within fetchmail > then that's got to make their lives (and by extension mine :>) easier. I know at least two very annoying bugs in older versions of fetchmail (I don't recall the version numbers offhand, but it's in the NEWS file): a. fetchmail not initializing the default certificate path in OpenSSL. Consequence: OpenSSL doesn't look at /etc/ssl/certs (or whatever the default path is). Workaround: use --sslcertpath /etc/ssl/certs b. fetchmail complaining if --sslcertck is NOT given, but a matching --sslfingerprint is. AFAIK no workaround except short of filtering them out from the log. Generally, there are two approaches of trusting the server's certificate: 1. The canonical and recommended one: verify the recognized Certification Authority's signature on the server certificate (that works for major CAs as their certificates are usually shipped with the OS or available as add-on, for instance, in FreeBSD's ca-roots port). /etc/ssl/certs contains certificates of CAs we trust (recognize) and is thus the configuration directory for the "trusted CAs". That is the usual way of doing things, and reasonable sites using self-signed certificates provide their root CA certificates for download with a web browser and usually offer a phone number you can call to verify the fingerprint. At least that's how my former and current universities and the DFN (at a very coarse look, they provide the Internet backbone to German Universities) do that. As to the major freemailers I have acocunts with, they have their server certificates signed by Thawte, Verisign, Equifax or whoever else that up-to-date distributions usually recognize as trusted. I'm not sure if it's always possible to download the CA's certificate with openssl s_client. 2. The less durable one: verify the server's certificate instead. The recommendation of downloading the certificate and stuffing it into /etc/ssl/certs however is just a very cumbersome alternative of specifying the sslfingerprint which fetchmail already prints at -v verbose level. Let's not tell users to use openssl s_client to download certificates, but let's just point them to the sslfingerprint option and tell them that they need a recent fetchmail. The only technical difference is we're using a hash of the certificate and are currently relying on MD5, but I'm not aware that attacks are publicly known to generate a message with a specific hash in a reasonable amount of time. Reason why I call 2 less durable is that CA certificates are usually valid for five years or longer and to a certain extent managed by the distributor, whereas server certificates often expire sooner, causing issues once a year or so. The wording above is perhaps not as clear as it could be if I revised this text several times, but let's just see where it's unclear and revise the critical parts. (And if that's going to evolve into a "SSL certificate management for fetchmail" section, that's exactly what I'm aiming at :-)) Best regards, -- Matthias Andree |
|
From: Rob M. <rob...@gm...> - 2007-08-23 09:50:57
|
On 8/23/07, Matthias Andree <mat...@gm...> wrote:
>
> Yes, older openssl s_client versions don't support as many protocols.
Even 0.9.8e, the most recent, appears to be less than 100% - it won't
talk TLS to my domain host's IMAP/POP servers (but fetchmail will).
<---SNIP--->
> Generally, there are two approaches of trusting the server's
> certificate:
>
> 1. The canonical and recommended one: verify the recognized
> Certification Authority's signature on the server certificate (that
> works for major CAs as their certificates are usually shipped with
> the OS or available as add-on, for instance, in FreeBSD's ca-roots
> port). /etc/ssl/certs contains certificates of CAs we trust
> (recognize) and is thus the configuration directory for the "trusted
> CAs".
>
> That is the usual way of doing things, and reasonable sites using
> self-signed certificates provide their root CA certificates for
> download with a web browser and usually offer a phone number you can
> call to verify the fingerprint.
> At least that's how my former and current universities and the DFN
> (at a very coarse look, they provide the Internet backbone to German
> Universities) do that.
Sadly, not all do. I'll need to check, but I'm pretty sure one of my
current mail hosts uses a self signed certificate and no way of
downloading the CA certificate.
> 2. The less durable one: verify the server's certificate instead.
>
> The recommendation of downloading the certificate and stuffing it
> into /etc/ssl/certs however is just a very cumbersome alternative of
> specifying the sslfingerprint which fetchmail already prints at -v
> verbose level. Let's not tell users to use openssl s_client to
> download certificates, but let's just point them to the
> sslfingerprint option and tell them that they need a recent fetchmail.
>
> The only technical difference is we're using a hash of the
> certificate and are currently relying on MD5, but I'm not aware that
> attacks are publicly known to generate a message with a specific hash
> in a reasonable amount of time.
I'm not aware of any easy way of generating a matching MD5, with valid
content, easily.
I suppose this raises a feature request then - when a certificate
fails to verify fetchmail should email the user specified in the poll
command (or the postmaster if multiple users are listed) to tell them.
> The wording above is perhaps not as clear as it could be if I revised
> this text several times, but let's just see where it's unclear and
> revise the critical parts. (And if that's going to evolve into a "SSL
> certificate management for fetchmail" section, that's exactly what I'm
> aiming at :-))
I don't have any problems understanding it, but then I have a
reasonable understanding of how SSL works :) I'll come back to it
later and have another read to see if I can spot anything the average
user of fetchmail may not understand.
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
|
From: Jakob H. <jh...@pl...> - 2007-08-23 11:56:27
|
Quoting Rob MacGregor: >> I don't know anything about your server, but it works fine here: >> >> $ openssl s_client -connect koi:pop3 -starttls pop3 >> CONNECTED(00000003) >> ... >> +OK Dovecot ready. <...> > Ok, I've just tried it on another host and it works there, just not on > my main host - which works fine with fetchmail's TLS support. The message "connect: Connection refused" you got with openssl sounds more like it couldn't even connect to the server. It may be worth tracing this problem with strace and tcpdump. Is your main server publically reachable? >> Right, but I don't hink that fetchmail is the right tool for that. On >> the other hand, it's not that hard to print the certificate. > From my results above it looks like the s_client functionality isn't > 100%, and it's use relies on people having the very latest version for > IMAP support (from your comment below). 0.9.8e is 6 months old, so I guess (or hope) it will be absorbed in the next version of $DISTRIBUTION. > History on the -users mailing list suggests that we really need to > make it easy for people to solve these problems. If it's simple > enough to provide all the required information from within fetchmail > then that's got to make their lives (and by extension mine :>) easier. As Matthias pointed out, the fingerprint is suitable for that. Don't get me wrong, I'm not against a "dump the server's cert" feature in fetchmail, it could be handy. But I'm not sure that what you want to do with it is The Right Thing. But then again, I didn't follow the discussion which lead you to start this thread. > It does however assume that everybody is using at least 0.9.8e :) I > suppose I'm mostly concerned about the poor souls who're using RPM > based distributions. It isn't always possible to upgrade one package Sure, even Fedora 7 uses 0.9.8b. But the same applies to fetchmail. Most people use the distribution's package, I guess. But upgrading fetchmail is admittedly quite easier, because of much less dependencies (if any). |
|
From: Rob M. <rob...@gm...> - 2007-08-23 12:27:54
|
On 8/23/07, Jakob Hirsch <jh...@pl...> wrote:
>
> The message "connect: Connection refused" you got with openssl sounds
> more like it couldn't even connect to the server. It may be worth
> tracing this problem with strace and tcpdump.
> Is your main server publically reachable?
It is, and it works fine (from the same host) with fetchmail or
telnet. I'll have a closer look tomorrow night, but I'm pretty sure
it's not a network problem :)
> 0.9.8e is 6 months old, so I guess (or hope) it will be absorbed in the
> next version of $DISTRIBUTION.
But lots of people won't/don't upgrade working systems if they don't
have to. Heck, I've got a Mandrake 9.0 box that's barely been touched
since it was installed.
> As Matthias pointed out, the fingerprint is suitable for that.
> Don't get me wrong, I'm not against a "dump the server's cert" feature
> in fetchmail, it could be handy. But I'm not sure that what you want to
> do with it is The Right Thing. But then again, I didn't follow the
> discussion which lead you to start this thread.
I'm beginning to lean towards the view that the fingerprint is fine.
I do think however that failed certificate verification should be
handled the same way a failed password verification is - emailed
notification upon the first occurrence.
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X