error from ISP when fetcmail runs
The following errors occur when I run fetchmail, the errors are not serious ie fetchmail still works. The first started around 6 months ago, the expired one only a few weeks ago. The ISP has never sent anything stating they were changing or upgrading any security. As far as I know nothing has changed at this end for fetchmail. fetchmail: Server certificate verification error: self signed certificate fetchmail: Server certificate verification error: certificate has expired Lindsay
The following errors occur when I run fetchmail, the errors are not serious ie fetchmail still works. The first started around 6 months ago, the expired one only a few weeks ago. The ISP has never sent anything stating they were changing or upgrading any security. As far as I know nothing has changed at this end for fetchmail.
fetchmail: Server certificate verification error: self signed certificate fetchmail: Server certificate verification error: certificate has expired
If you want the error go to away then turn off TLS. The only thing you are getting out of it is encryption, but that's of little value when you have no idea that you are communicating with the right server, which is the whole point of TLS/SSL. James
On Tue, Mar 06, 2012 at 10:13:20PM +0000, James Harper wrote:
fetchmail: Server certificate verification error: self signed certificate fetchmail: Server certificate verification error: certificate has expired
If you want the error go to away then turn off TLS.
you're telling him to misconfigure fetchmail so that it sends his login and password in clear text over the internet. bad advice.
The only thing you are getting out of it is encryption, but that's of little value when you have no idea that you are communicating with the right server, which is the whole point of TLS/SSL.
Wrong on both points. encryption alone is incredibly valuable, and encryption is the whole point of TLS/SSL. identify verification is a secondary, and entirely optional, point. For many purposes, encryption is all that's needed. connecting to your ISP's mail server, for example. or to some dinky little forum site. Certificate verification is only required when it's important that the host you are connecting to is actually who they claim to be (or, at least, that some trusted third party says that they are). Your bank, for example. ebay and paypal for two more. and high-profile, ubiquitous sites like google where a stolen login & password could lead to identity theft. Note Well, however: blindly trusting a cert issued by a commercial CA isn't much (if any) safer than just blindly trusting a self-signed cert. there have been enough compromises of commercial CAs over the years (some of them VERY high profile) to prove that beyond doubt. Judgement is required of the end-user. Unfortunately, this is another way of saying "we're all doomed, PKI is hopelessly compromised" :) craig -- craig sanders <cas@taz.net.au> BOFH excuse #294: PCMCIA slave driver
On Tue, Mar 06, 2012 at 10:13:20PM +0000, James Harper wrote:
fetchmail: Server certificate verification error: self signed certificate fetchmail: Server certificate verification error: certificate has expired
If you want the error go to away then turn off TLS.
you're telling him to misconfigure fetchmail so that it sends his login and password in clear text over the internet. bad advice.
Are you sure the choices are only plaintext or TLS/SSL?? I haven't used fetchmail in nearly a decade but I'm sure there were challenge/response authentication methods available. If I'm wrong about that and the choices really are plaintext or TLS/SSL then I withdraw my suggestion.
The only thing you are getting out of it is encryption, but that's of little value when you have no idea that you are communicating with the right server, which is the whole point of TLS/SSL.
Wrong on both points. encryption alone is incredibly valuable, and encryption is the whole point of TLS/SSL. identify verification is a secondary, and entirely optional, point.
For many purposes, encryption is all that's needed. connecting to your ISP's mail server, for example. or to some dinky little forum site.
Certificate verification is only required when it's important that the host you are connecting to is actually who they claim to be (or, at least, that some trusted third party says that they are). Your bank, for example. ebay and paypal for two more. and high-profile, ubiquitous sites like google where a stolen login & password could lead to identity theft.
I disagree. If you can't be sure of who you are connecting to then you have already lost. You may be sitting in an internet café quite happily conducting an encrypted connection to a man-in-the-middle. If you information is worth securing then it is worth securing properly. As you say below the informed user would weigh up the pro's and con's of each situation and act accordingly, but just dismissing the identification aspect of SSL is a mistake.
Note Well, however: blindly trusting a cert issued by a commercial CA isn't much (if any) safer than just blindly trusting a self-signed cert. there have been enough compromises of commercial CAs over the years (some of them VERY high profile) to prove that beyond doubt.
Judgement is required of the end-user. Unfortunately, this is another way of saying "we're all doomed, PKI is hopelessly compromised" :)
Well yes, ideally you would receive a tamper-evident letter from your bank containing the public key, or at least a hash of the public key, and then no third-party trust is required. But I think there is a world of difference between trusting a self-signed cert and a cert that chains to a commercial CA. Nothing is perfect though. James
On Tue, Mar 06, 2012 at 10:13:20PM +0000, James Harper wrote:
fetchmail: Server certificate verification error: self signed certificate fetchmail: Server certificate verification error: certificate has expired
If you want the error go to away then turn off TLS.
you're telling him to misconfigure fetchmail so that it sends his login and password in clear text over the internet. bad advice.
Are you sure the choices are only plaintext or TLS/SSL??
I haven't used fetchmail in nearly a decade but I'm sure there were challenge/response authentication methods available. If I'm wrong about that and the choices really are plaintext or TLS/SSL then I withdraw my suggestion.
This makes for interesting reading... http://catb.org/~esr/fetchmail/fetchmail-FAQ.html#G10 James
On Tue, Mar 06, 2012 at 11:00:56PM +0000, James Harper wrote:
The only thing you are getting out of it is encryption, but that's of little value when you have no idea that you are communicating with the right server, which is the whole point of TLS/SSL.
Wrong on both points. encryption alone is incredibly valuable, and encryption is the whole point of TLS/SSL. identify verification is a secondary, and entirely optional, point. [...]
I disagree. If you can't be sure of who you are connecting to then you have already lost.
since you can't actually trust commercial CAs, then you've lost just as badly as if you trust a self-signed cert.
You may be sitting in an internet café quite happily conducting an encrypted connection to a man-in-the-middle. If you information is worth securing then it is worth securing properly. As you say below the informed user would weigh up the pro's and con's of each situation and act accordingly, but just dismissing the identification aspect of SSL is a mistake.
i'm not dismissing it. I'm saying that it's not relevant in some, possibly even many or most, situations. situations where encryption to deter casual interception is sufficient. the meaning of "securing properly" varies depending on the circumstances - how important privacy is, what the risks and consequences of compromise are. and anyone who does internet banking in an internet cafe is a fuckwit who has only themself to blame when their bank account is emptied. e.g. if i were running an internet cafe, I could buy certificates for paypal, google, various internet banks etc from a rogue commercial CA - call them Komodo, like the giant lizard, for an entirely fictional hypothetical example :) - and divert all related traffic to my own bogus versions of those sites. The end-user using their laptop in my cafe would be none-the-wiser. The certs *would* be signed by a CA cert that their browser had pre-installed to trust. There would be no warning, no sign that there was anything wrong. and if you're conducting a private conversation that you *really* don't want intercepted then the *ONLY* way to ensure that is to exchange keys with the person you're talking to - i.e. trust the key that THEY gave you, not the key that some third-party (a commercial CA) says is the right one. you could do this directly (e.g. effectively a two-person web of trust), or by using the existing web of trust infrastructure.
Well yes, ideally you would receive a tamper-evident letter from your bank containing the public key, or at least a hash of the public key, and then no third-party trust is required. But I think there is a world of difference between trusting a self-signed cert and a cert that chains to a commercial CA.
it's entirely situational. In some cases, identity verification just doesn't matter at all. when all you want is encryption so your traffic can't easily be snooped. e.g so you can be reasonably sure that some script-kiddie sitting near you in the cafe doesn't steal the password to your myfavouritehobby.org forum and troll in your name. In some cases, it does matter. banking is the obvious example where trusting a self-signed cert would be a bad idea. but that doesn't mean that blindly trusting a commercial CA is a good idea. IMO commercial CAs, and the entire commercial PKI industry are a scam. Netscape fucked up big time when they invented that. They had a chance to establish a web-of-trust as the industry standard, but they wanted to cash in on being the gatekeepers to an artificial monopoly. i'd trust a bank certificate that happened to be co-signed by several other banks, the banking industry ombudsman and a few other relevant parties FAR MORE than i trust a key signed by some commercial CA. And, because the bank created the key themselves, it would be less likely that a copy of the private key could be stolen from the CA or handed over as a matter of course to some governmental spool agency. A commercial CA is a single point of failure, just one place that needs to be compromised - hacked, blackmailed, subverted, run as a TLA agency front, etc. A web of trust is far harder to compromise, especially when the parties (other banks, in this instance) are putting their reputations on the line when they sign a key. I don't really trust my bank's certificate....there just isn't enough information available for me to do that. Sure, it's signed by a commercial CA but I have no way of knowing if that CA has been compromised or not...or that I'm getting the bank's real site and real cert and haven't been redirected to a bogus site using a bogus cert from a rogue CA. and, IMO, I would be a fool if i ever allowed myself to become complacent and forget that. I accept the cert mostly because I don't have any choice if want to do online banking. and even then, i only login from home (where i keep the little push-button auth token they supplied) from a web browser that I never use for anything else.
Nothing is perfect though.
absolutely true. there's no such thing as perfect security. can not be achieved. what *can* be achieved is security that is good enough to meet the current purpose, especially if that current purpose is low risk (or the risk has low consequences) the higher the risk, the more effort you need to put in to secure the connection. craig -- craig sanders <cas@taz.net.au> BOFH excuse #187: Reformatting Page. Wait...
On Tue, Mar 06, 2012 at 11:00:56PM +0000, James Harper wrote:
The only thing you are getting out of it is encryption, but that's of little value when you have no idea that you are communicating with the right server, which is the whole point of TLS/SSL.
Wrong on both points. encryption alone is incredibly valuable, and encryption is the whole point of TLS/SSL. identify verification is a secondary, and entirely optional, point. [...]
I disagree. If you can't be sure of who you are connecting to then you have already lost.
since you can't actually trust commercial CAs, then you've lost just as badly as if you trust a self-signed cert.
There's liability to consider to. If your bank account is emptied because a commercial CA was compromised then you should have no trouble getting the bank to make things right again - it's not your fault that they made a bad decision in who to trust. It will certainly be inconvenient but the actual loss should be minimal.
You may be sitting in an internet café quite happily conducting an encrypted connection to a man-in-the-middle. If you information is worth securing then it is worth securing properly. As you say below the informed user would weigh up the pro's and con's of each situation and act accordingly, but just dismissing the identification aspect of SSL is a mistake.
i'm not dismissing it. I'm saying that it's not relevant in some, possibly even many or most, situations. situations where encryption to deter casual interception is sufficient. the meaning of "securing properly" varies depending on the circumstances - how important privacy is, what the risks and consequences of compromise are.
and anyone who does internet banking in an internet cafe is a fuckwit who has only themself to blame when their bank account is emptied.
e.g. if i were running an internet cafe, I could buy certificates for paypal, google, various internet banks etc from a rogue commercial CA - call them Komodo, like the giant lizard, for an entirely fictional hypothetical example :) - and divert all related traffic to my own bogus versions of those sites. The end-user using their laptop in my cafe would be none-the-wiser. The certs *would* be signed by a CA cert that their browser had pre-installed to trust. There would be no warning, no sign that there was anything wrong.
Yes this is a problem. DNS poisoning is always a possibility though, and you are only marginally safer at home. One thing I wish my browser would tell me is when a cert has changed. Eg: Warning: This site previously used a certificate signed by Verisign and owned by bigbank pty ltd, but the certificate presented today is signed by CheapCA and is owned by bankofnigeria pty ltd. Are you sure you want to proceed? or even: Warning: The previous certificate for this site was due to expire in 2014 but has been replaced today and has not been revoked. Please confirm that this is expected. So basically any unexpected change in certificate. The only expected change would be one where the cert was about due to expire and replaced with a renewed cert (with all other details the same), or (maybe) a new certificate with the same signing details with the previous certificate having been revoked, although I'd probably like to see a warning in that case too if only for curiosity's sake. Maybe such a plugin already exists??
and if you're conducting a private conversation that you *really* don't want intercepted then the *ONLY* way to ensure that is to exchange keys with the person you're talking to - i.e. trust the key that THEY gave you, not the key that some third-party (a commercial CA) says is the right one. you could do this directly (e.g. effectively a two-person web of trust), or by using the existing web of trust infrastructure.
Agreed. James
On Tue, Mar 06, 2012 at 11:00:56PM +0000, James Harper wrote:
But I think there is a world of difference between trusting a self-signed cert and a cert that chains to a commercial CA.
Which do you trust more: 1. a certificate signed by a CA cert that was pre-installed into your OS or browser as a result of some corporate deal? 2. a certificate signed by a CA cert that you got directly from your correspondent and installed by you into your browser or OS? *THAT* is the sum total of the difference between a commercial cert and a self-signed cert. commercial CAs are, at best, just a convenience so ignorant end-users don't have to think about the issues involved. and convenience is the enemy of security. To me, 2. is far more worthy of my trust than 1., but I'd prefer an option 3 (which doesn't exist for ssl/tls AFAIK): 3. a certificate signed by several (the more the better) other certificates in a large web of trust. craig -- craig sanders <cas@taz.net.au> BOFH excuse #212: Of course it doesn't work. We've performed a software upgrade.
On Tue, Mar 06, 2012 at 11:00:56PM +0000, James Harper wrote:
But I think there is a world of difference between trusting a self-signed cert and a cert that chains to a commercial CA.
Which do you trust more:
1. a certificate signed by a CA cert that was pre-installed into your OS or browser as a result of some corporate deal?
2. a certificate signed by a CA cert that you got directly from your correspondent and installed by you into your browser or OS?
I'd trust #2 of course, if the certificate was handed to me directly by the person who's arse is on the line if things went wrong. What I don't trust is that my bank can deliver that certificate to me in a manner that I would trust any more than the pre-installed CA. You only have to look at the steps banks fail to make in preventing credit card fraud to shake your faith in this. The generation and delivery would be outsourced to the lowest bidder, the tamper evident envelope would be easy to subvert (in terms of the general population being able to identify this), and they'd just use Australia Post to deliver it and place it in your letterbox for anyone to swap over. Even if they made you physically go to the bank to pick up the CA thumbprint there is still plenty of room for it to go wrong. Once you had it in your hands though you are in a much better position than #1. Fortunately, there are hundreds of ways of ripping off the general population without the bad guys having to think about doing any of the above, so I think we're pretty safe for the time being. James
Craig Sanders wrote:
To me, 2. is far more worthy of my trust than 1., but I'd prefer an option 3 (which doesn't exist for ssl/tls AFAIK):
3. a certificate signed by several (the more the better) other certificates in a large web of trust.
Nitpick: you're talking about X.509, not TLS. It is *probably* technically possible to use TLS with trust managed via a GPG trust model, in the same way monkeysphere uses GPG to manage SSH trust. Of course, you'd have to patch the both ends of the TLS connection, so in the context of "everything is a browser" it's unlikely to fly.
Trent W. Buck <trentbuck@gmail.com> wrote:
Nitpick: you're talking about X.509, not TLS.
Even in X.509, there is provision for bridging certificates, cross-certificates, etc. I haven't investigated how these work; they aren't equivalent to a PGP-style web of trust, but I understand that CAs can certify each other. The farthest I have come along this road was to create my own CA and to issue certificates for my hosts.
Trent W. Buck <trentbuck@gmail.com> wrote:
Nitpick: you're talking about X.509, not TLS.
Even in X.509, there is provision for bridging certificates, cross-certificates, etc. I haven't investigated how these work; they aren't equivalent to a PGP- style web of trust, but I understand that CAs can certify each other.
The farthest I have come along this road was to create my own CA and to issue certificates for my hosts.
To load a driver into a 64 bit Windows kernel (except for 2003) it has to be signed, and it has to be signed by a certificate that chains back to Microsoft's CA, which means you also have to use one of the Microsoft cross-certificates (which limits your choice of CA although there is a large number to choose from now). In addition you need to have the driver signed by a recognised timestamp server to prove that your binary was signed during the time that your certificate was valid (unless you want the binary to expire with the certificate). Given that all that is possible and not even really difficult I assume that what you are saying is achievable. James
On Wed, Mar 07, 2012 at 11:25:12AM +1100, Craig Sanders wrote:
3. a certificate signed by several (the more the better) other certificates in a large web of trust.
DNSSEC + DANE looks pretty good too. http://tools.ietf.org/html/draft-ietf-dane-protocol-12 in short: publish a fingerprint for the ssl key as a DNS resource record. still draft, and AFAIK, no browsers support it yet. more interesting reading: http://www.networkworld.com/news/2011/101211-ssl-moxie-marlinspike-251882.ht... (the article refers to the compromises of Comodo, Diginotar, etc as "shocking". anyone who's been paying attention or even thought about how the CA industry works would have said "inevitable" rather than "shocking") and this: http://www.networkworld.com/news/2011/081811-ssl-249874.html which links to Marlinspike's web-of-trust style plugin for firefox: http://convergence.io/ and another implementation of a similar idea, from Carnegie Mellon uni: http://perspectives-project.org/ craig -- craig sanders <cas@taz.net.au> BOFH excuse #225: It's those computer people in X {city of world}. They keep stuffing things up.
Craig Sanders wrote:
On Wed, Mar 07, 2012 at 11:25:12AM +1100, Craig Sanders wrote:
3. a certificate signed by several (the more the better) other certificates in a large web of trust.
DNSSEC + DANE looks pretty good too.
+1.
which links to Marlinspike's web-of-trust style plugin for firefox: http://convergence.io/
Which makes me wonder (again) why we're still doing authentication and encryption at the application layer instead (TLS) of at the internet layer (IPsec).
On Wed, 7 Mar 2012, Craig Sanders wrote:
On Tue, Mar 06, 2012 at 10:13:20PM +0000, James Harper wrote:
fetchmail: Server certificate verification error: self signed certificate fetchmail: Server certificate verification error: certificate has expired
If you want the error go to away then turn off TLS.
you're telling him to misconfigure fetchmail so that it sends his login and password in clear text over the internet. bad advice.
The only thing you are getting out of it is encryption, but that's of little value when you have no idea that you are communicating with the right server, which is the whole point of TLS/SSL.
Wrong on both points. encryption alone is incredibly valuable, and encryption is the whole point of TLS/SSL. identify verification is a secondary, and e
Lots of goodstuff cutout
Judgement is required of the end-user. Unfortunately, this is another way of saying "we're all doomed, PKI is hopelessly compromised" :)
craig
Thanks all for the responses they have been most helpfull. I did a "fetchmail -v" and it seems my ISP has enabled TLS without any kind of announcement. A point before i discuss this further, I all most __NEVER__ (excuse the shouting) do business to a faceless anything, I always require somekind of shopfront and/or person I can directly deal with. It would be safe to say the only transactions I have carried out on the net is to get Debian from some of the very kind people on this list. 99.7% of my email will be to one particular address, I of course do not need to say which one. As to TLS Craig and at least one other has pointed out what I consider to be the serious flaw here. Now some time back I did a good deal of study on PGP and that kind of thing. Inspite of the great hype going I almost at once came up with its most serious flaw, how do you know if the public key is valid and is not the result of some kind of forgery. Downloading a key off the net is no security at all. For instance how do I know the public key to one of the Debian disributions required be Secure APT has not been forged, the answer is I do not. All this key proves is the distibution is effectively all one but not its origin. I have looked at the mathematics and I will grant here that the public and the private key defintely go togther, but that is not the problem here. As far as I am concerned securing a link to a mail server by a public availble key is effectively no security and as I have indicated above I would never trust such a link. Gets off soap box ;-), I am currently studing the Fetchmail FAQ and RFC2595 and will see how I go, the easist path is to simply disable TLS, I will though do some more study. many thanks for the help, Lindsay
On Wed, Mar 07, 2012 at 08:48:08AM +1100, Lindsay Sprinter wrote:
The following errors occur when I run fetchmail, the errors are not serious ie fetchmail still works. The first started around 6 months ago, the expired one only a few weeks ago. The ISP has never sent anything stating they were changing or upgrading any security. As far as I know nothing has changed at this end for fetchmail.
fetchmail: Server certificate verification error: self signed certificate fetchmail: Server certificate verification error: certificate has expired
unless you're expecting to verify your POP/IMAP/SMTP/etc connections, it really doesn't matter. a self-signed certificate, even an expired one, still works perfectly well for encrypting the connection. if it's stopping fetchmail from actually fetching your mail, then see if there's an option to stop fetchmail from verifying certs. or try to get a copy of their root certificate and install it where fetchmail can use it (probably /etc/ssl/certs). If it isn't stopping the mail from being fetched just treat it as a warning and ignore it. oh, and email your ISP's sysadmins and tell them they need to resign their certificate. and maybe publish their CA certificate so their users can download and install it. (FYI, I have a self-signed cert on my system, for postfix and dovecot and apache. i made it to be valid for 10 years so I don't have to resign it every year. for my needs, it works fine. if my system ever gets hacked and the private key stolen, i'll issue a revocation and create a new one). self-signed just means they created and signed the cert themselves (probably using openssl's CA.pl as a Certificate Authority) rather than paying a commercial CA. The only real advantage of a commercial CA is that the public portion of their root cert is widely distributed and often included by default in operating systems and browsers so that the signature can be verified. While you probably want your bank's web site to use a reputable commercial CA, for anything else where you just want encryption but don't care about verification, a self-signed cert is fine. e.g. encrypting the login page on a forum site. it's not uncommon for sites using a self-signed certificate to publish their own CA cert so that end-users can skip the scary warnings (which are mostly self-serving advertisements to bolster the artificial public key infrastructure industry). craig ps: there are so many commercial CAs to choose from. some even make a decent attempt to verify your identity when you request a certificate. others will cheerfully sell you a cert for google.com or whatever you want. apart from that, you have the choice of having your private key secretly passed on to the CIA, NSA, Mossad, Iranian government hackers, or any other spook agency of your choice (if you can figure out who is owned by whom)...hell, ASIO may even have their own pet CA. -- craig sanders <cas@taz.net.au> BOFH excuse #39: terrorist activities
participants (5)
-
Craig Sanders -
James Harper -
Jason White -
Lindsay Sprinter -
Trent W. Buck