headers
Jerry | 1 Mar 2011 14:29
Face

Re: strange polling errors

On Mon, 28 Feb 2011 19:05:07 +0100
Matthias Andree <matthias.andree <at> gmx.de> articulated:

> However, Jonathan stated earlier he had difficulties determining the
> Exchange server's version.  Exchange 2003 as provided by Alice DSL
> Germany greets me with "version 6.5.mumble" in case that helps.

I was surprised to discover that servers are not required to disclose
their versions.

   "SMTP server implementations MAY include identification of their
   software and version information in the connection greeting reply
   after the 220 code, a practice that permits more efficient isolation
   and repair of any problems.  Implementations MAY make provision for
   SMTP servers to disable the software and version announcement where
   it causes security concerns.  While some systems also identify their
   contact point for mail problems, this is not a substitute for
   maintaining the required "postmaster" address (see Section 4)."

http://www.ietf.org/rfc/rfc5321.txt

Microsoft does by default configure its Exchange servers to display
their version information. However, any admin can easily modify that. I
don't know of anything that the OP can do to alleviate that problem.

--

-- 
Jerry ✌
Fetchmail.user <at> seibercom.net

Disclaimer: off-list followups get on-list replies or get ignored.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matthias Andree | 1 Mar 2011 14:46
Picon
Picon

Re: strange polling errors

Am 01.03.2011 14:29, schrieb Jerry:

> I was surprised to discover that servers are not required to disclose
> their versions.
> 
>    "SMTP server implementations MAY include identification of their
> [...]
> http://www.ietf.org/rfc/rfc5321.txt
> 
> Microsoft does by default configure its Exchange servers to display
> their version information. However, any admin can easily modify that. I
> don't know of anything that the OP can do to alleviate that problem.

It would appear that we're talking about Exchange's IMAP support here,
where RFC5321 doesn't apply, but instead RFC3501.

Not that it matters much for the problem at hand though.
Permalink | Reply | 0 comments |
headers
Perry Hutchison | 1 Mar 2011 22:05
Favicon

Re: fetchmail gmail set up problem

> It's no good marking a server certificate as trusted (by
> copying it into $SSLDIR/certs).  People need to install
> the root certificate that signed the server certificate,
> not the server certificate itself!

Can someone point to a good explanation of _why_ trusting the server
certificate directly is insecure?  I've just had (what looks to me
like) the same issue arise with an Exchange server -- it has gotten
a new certificate whose root signing certificate is not installed --
and the IT folks are saying to just accept the server certificate
itself.  I doubt I'll be able to convince them otherwise without
a comprehensible explanation of why it's a bad idea.  (They are
actually referring to Evolution/Thunderbird -- they don't "support"
fetchmail -- but I don't suppose the choice of client affects the
security considerations.)
Permalink | Reply | 5 comments |
headers
Rob MacGregor | 2 Mar 2011 08:21
Picon
Gravatar

Re: fetchmail gmail set up problem

On Tue, Mar 1, 2011 at 21:05, Perry Hutchison <phutchis <at> windriver.com> wrote:
> Can someone point to a good explanation of _why_ trusting the server
> certificate directly is insecure?

Two main reasons:

 1. How do you know that it's really the valid certificate? What about
when it changes? With a CA at least you can usually verify it (though
obviously with in-house CAs that can be harder)

 2. It teaches people that the "right thing" to do is to blindly
accept the remote certificate no matter what. Look at the number of
people that if they reach a CA with an untrusted certificate blindly
click through and accept it.

--

-- 
                 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
_______________________________________________
fetchmail-users mailing list
fetchmail-users <at> lists.berlios.de
https://lists.berlios.de/mailman/listinfo/fetchmail-users
Permalink | Reply | 0 comments |
headers
Matthias Andree | 2 Mar 2011 12:58
Picon
Picon

server certificates (was: fetchmail gmail set up problem)

I wrote:

> > It's no good marking a server certificate as trusted (by
> > copying it into $SSLDIR/certs).  People need to install
> > the root certificate that signed the server certificate,
> > not the server certificate itself!

Perry Hutchison asked:

> Can someone point to a good explanation of _why_ trusting the server
> certificate directly is insecure?  [...]
> the IT folks are saying to just accept the server certificate
> itself.  I doubt I'll be able to convince them otherwise without
> a comprehensible explanation of why it's a bad idea. [...]

Which is clueless and creates a false sense of security -- unless they provide you with certificate
fingerprints that you need to verify before marking the certificate trusted.

There are several considerations:

1. instructions to obtain and/or accept the server certificate as trusted usually rely on a direct
download of the server certificate. The communications channel is the same that fetchmail would use.

Any man-in-the-middle attacker can and will replace the server certificate in a way that makes the end
believe it were the authentic server certificate, like copying and pasting server names, creation and
expiration dates, issuer, and all that.  

The openssl s_client and copy-and-paste-the-cert instructions afoot throughout the web all have this problem.

This setup could only be secure if people were told to verify the certificate finger prints and only install
(Continue reading)

Permalink | Reply | 3 comments |
headers
Perry Hutchison | 3 Mar 2011 05:20
Favicon

Re: server certificates (was: fetchmail gmail set up problem)

<snip excellent explanation>

> Is that clear, or does that leave further questions open?  I'm
> happy to answer more questions and possibly refine the README.SSL
> and/or FAQ that ships with fetchmail.  This is really important.

Let me restate my understanding, to see if I have it right:

----

  The problem is not with trusting a server's certificate
  (vs the root certificate which signed it) as such, but with
  authenticating a certificate -- any certificate -- before
  trusting it.  The authentication problem needs to be solved:

  * Whenever the trusted certificate changes (e.g. due to
    expiration).  This will typically happen more frequently
    with server certificates than with root certificates.

  * For each certificate that is to be trusted.  Authenticating
    (and subsequently trusting) a single root certificate covers
    any number of server certificates signed by that root.

  Therefore there is a lot more authentication work involved, with
  attendant opportunities for mistakes and/or use of insecure
  shortcuts, when trusting server certificates than when trusting
  only root certificates.

----
(Continue reading)

Permalink | Reply | 2 comments |
headers
Matthias Andree | 3 Mar 2011 21:34
Picon
Picon

Re: server certificates

Am 03.03.2011 05:20, schrieb Perry Hutchison:
> <snip excellent explanation>
> 
>> Is that clear, or does that leave further questions open?  I'm
>> happy to answer more questions and possibly refine the README.SSL
>> and/or FAQ that ships with fetchmail.  This is really important.
> 
> Let me restate my understanding, to see if I have it right:
> 
> ----
> 
>   The problem is not with trusting a server's certificate
>   (vs the root certificate which signed it) as such, but with
>   authenticating a certificate -- any certificate -- before
>   trusting it.  The authentication problem needs to be solved:
> 
>   * Whenever the trusted certificate changes (e.g. due to
>     expiration).  This will typically happen more frequently
>     with server certificates than with root certificates.
> 
>   * For each certificate that is to be trusted.  Authenticating
>     (and subsequently trusting) a single root certificate covers
>     any number of server certificates signed by that root.
> 
>   Therefore there is a lot more authentication work involved, with
>   attendant opportunities for mistakes and/or use of insecure
>   shortcuts, when trusting server certificates than when trusting
>   only root certificates.

More fundamentally, you need to have ways to make sure that any
(Continue reading)

Permalink | Reply | 1 comment |
headers
Perry Hutchison | 4 Mar 2011 00:12
Favicon

Re: server certificates

> >   The problem is not with trusting a server's certificate
> >   (vs the root certificate which signed it) as such, but with
> >   authenticating a certificate -- any certificate -- before
> >   trusting it ...
> >   There is a lot more authentication work involved, with
> >   attendant opportunities for mistakes and/or use of insecure
> >   shortcuts, when trusting server certificates than when
> >   trusting only root certificates.

> More fundamentally, you need to have ways to make sure that any
> certificate that you use for authentication purposes is really
> the one it pretends to be ...

That's what I meant by "authenticating _a certificate_ before
trusting it", but I can see where that wording might leave room
for confusion since there are at least three different (although
interrelated) authentication processes:

1.  What I called "authenticating the certificate":  making sure
    that the certificate is really the one it claims to be.  SSL
    does this automatically and transparently, _if_ the certificate
    in question is signed by an already-trusted certificate.
    Ultimately, however, there has to be at least one certificate
    which the SSL administrator has defined as trusted in its own
    right, without resort to signatures.  The process by which that
    trust is established can't be fully automated.

2.  Using the certificate to authenticate the server to which it
    was issued.  SSL does this automatically and transparently,
    based on its store of certificates "trusted in their own right"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Amalafrida | 6 Mar 2011 18:50
Picon

step-by-step

Ok. I've been working to install fetchmail for a bit, on my own. not much
success, thus my appearance here.

i'll take it from the top.

running ubuntu 10.04.2 and working towards fetching mail from gmail.

downloaded fetchmail-6.3.19.tar.bz2 & decompressed it.

after reading README and CONFIGURE files:
$./configure --with-ssl
....
configure: error: SSL support enabled, but OpenSSL not found

however,
$which openssl
/usr/bin/openssl

what to do? perhaps tell ./configure where to find openssl?

thanks in advance for any constructive advice.
Permalink | Reply | 6 comments |
headers
Rob MacGregor | 6 Mar 2011 19:05
Picon
Gravatar

Re: step-by-step

On Sun, Mar 6, 2011 at 17:50, Amalafrida <amalafrida <at> gmail.com> wrote:
> Ok. I've been working to install fetchmail for a bit, on my own. not much
> success, thus my appearance here.
>
> i'll take it from the top.
>
> running ubuntu 10.04.2 and working towards fetching mail from gmail.
>
> downloaded fetchmail-6.3.19.tar.bz2 & decompressed it.
>
> after reading README and CONFIGURE files:
> $./configure --with-ssl
> ....
> configure: error: SSL support enabled, but OpenSSL not found
>
> however,
> $which openssl
> /usr/bin/openssl
>
> what to do? perhaps tell ./configure where to find openssl?

You need to install the OpenSSL development libraries, not just the
executable. Try:

 aptitude install libssl-dev

Generally when installing from source, errors about packages not found
refer to the libraries, not the executables. Ubuntu, like many other
distros splits the libraries into 2 parts - the library itself (eg
libssl) that's used by executables and the development parts that are
(Continue reading)

Permalink | Reply | 0 comments |

Gmane