Vodafone/Ihug POP server cert has expired
Lawrence D'Oliveiro
fetchmail: Server certificate verification error: certificate has
expired
This is connecting to pop3.ihug.co.nz. I just tried a keyword search for
"pop3" at vodafone.co.nz, but they don't seem to have any page showing what
else to use, or indeed any list of recommended configuration settings at
all.
Yeah I know, I could turn off SSL/TLS in my fetchmail settings. Just what
any security n00b would do...
Stephen Worthington
Just what is so insecure about connecting unencrypted to your own
ISP's mail server? Unless you think your ISP is running a network
where their DNS has been hacked, it should be just fine.
Lawrence D'Oliveiro
wrote:
> Just what is so insecure about connecting unencrypted to your own
> ISP's mail server?
Yeah, there's a point, considering it's hardly the weakest point in the
chain...
AD.
<step...@jsw12.gen34.nz56.remove_numbers> wrote:
> Just what is so insecure about connecting unencrypted to your own
> ISP's mail server? Unless you think your ISP is running a network
> where their DNS has been hacked, it should be just fine.
Unless you're roaming and using some random public connection
somewhere. But yeah, it wouldn't normally bother me much either.
--
Cheers
Anton
Lawrence D'Oliveiro
> Starting at noon, my ten-minutely fetchmail crontask is now failing with
>
> fetchmail: Server certificate verification error: certificate has
> expired
I figured it out. I'm not actually asking fetchmail to use SSL/TLS: it's
automatically doing so because the POP server advertises that it supports
STLS.
There's no explicit option in fetchmail to turn this off, but if I tell it
to use SSL specifically, this causes it to skip the TLS negotiation and I
don't get the certificate expiry warning any more.
And it is just a warning; I am still getting mail.
Lawrence D'Oliveiro
> You should always treat all networks as if they were compromised (packet
> sniffing etc) in some way and use the most secure connections available to
> you.
Before you can formulate a practicable security plan, you have to know what
sort of threats exactly you think you're guarding against.
Stephen Worthington
<Beau...@Carnations.com> wrote:
>On Fri, 18 Sep 2009 21:20:45 +1200, Stephen Worthington wrote:
>
>> Just what is so insecure about connecting unencrypted to your own ISP's
>> mail server? Unless you think your ISP is running a network where their
>> DNS has been hacked, it should be just fine.
>
>You should always treat all networks as if they were compromised (packet sniffing etc) in some way
>and use the most secure connections available to you.
If your ISP's network is so compromised that someone else is doing
packet sniffing on it, then surely they would have access to the POP3
server already and have access to your email. And your ISP has no
trouble accessing your email on their own server. I really think that
encrypting a connection to your ISP's POP3 server is overkill (unless
you are outside the ISP's network, of course). If you want to secure
your emails, they need to be encrypted themselves, at source.
Lawrence D'Oliveiro
> And yes - I agree - confidential emails should be encrypted from source -
> as should their replies.
Which would be better--public-key or secret-key encryption?
Lawrence D'Oliveiro
> There's no explicit option in fetchmail to turn this off, but if I tell it
> to use SSL specifically, this causes it to skip the TLS negotiation and I
> don't get the certificate expiry warning any more.
Nope, this doesn't work. So now I'm doing
fetchmail -sf ~/etc/fetchmailrc 2>&1 | grep -v "certificate has expired"
to ignore the warning.
Stephen Worthington
Public key is much easier, as you do not have to have some secret way
of sending a key. AFAIK, they are both equally good encryptions.
Stephen Worthington
Maybe you should get the source and do a patch to add an option, then
send it back to the developers.
Lawrence D'Oliveiro
wrote:
> On Sun, 20 Sep 2009 12:15:22 +1200, Lawrence D'Oliveiro
> <l...@geek-central.gen.new_zealand> wrote:
>
>>In message <pan.2009.09...@carnations.com>, Carnations wrote:
>>
>>> And yes - I agree - confidential emails should be encrypted from source
>>> - as should their replies.
>>
>>Which would be better--public-key or secret-key encryption?
>
> Public key is much easier, as you do not have to have some secret way
> of sending a key.
But you still have the problem of trusting the public key.
> AFAIK, they are both equally good encryptions.
It's not either/or. :)
Lawrence D'Oliveiro
wrote:
> Maybe you should get the source and do a patch to add an option, then
> send it back to the developers.
Yeah, I thought about that. But it turns out this is a known issue. From the
FAQ:
Some servers advertise STLS (POP3) or STARTTLS (IMAP), and fetchmail
will automatically attempt TLS negotiation if SSL was enabled at
compile time. This can however cause problems if the upstream didn't
configure his certificates properly.
In order to prevent fetchmail from trying TLS (STLS, STARTTLS)
negotiation, add this option:
sslproto ssl23
This restricts fetchmail's SSL/TLS protocol choice from the default
"SSLv2, SSLv3, TLSv1" to the two SSL variants, disabling TLSv1. Note
however that this causes the connection to be unencrypted unless an
encrypting "plugin" is used or SSL is requested explicitly.
And yes, that does work.
Stephen Worthington
<l...@geek-central.gen.new_zealand> wrote:
>In message <5r2bb55kgefg4guuv...@4ax.com>, Stephen Worthington
>wrote:
>
>> On Sun, 20 Sep 2009 12:15:22 +1200, Lawrence D'Oliveiro
>> <l...@geek-central.gen.new_zealand> wrote:
>>
>>>In message <pan.2009.09...@carnations.com>, Carnations wrote:
>>>
>>>> And yes - I agree - confidential emails should be encrypted from source
>>>> - as should their replies.
>>>
>>>Which would be better--public-key or secret-key encryption?
>>
>> Public key is much easier, as you do not have to have some secret way
>> of sending a key.
>
>But you still have the problem of trusting the public key.
In the same way that you have a problem trusting a private key that is
sent to you somehow. Only it is much easier to get the key. You can
freely publish your public key on your web page with no loss of
security. If the person you want to email is the owner of that web
page and that is the only way you know him, then you can trust his
public key from there as much as any other way he might get you a key
(unless his web server has been hacked). There is always a problem
trusting the initial setup of secure communications. At some point,
you just have to decide to trust something and go ahead and see how it
works out.
>> AFAIK, they are both equally good encryptions.
>
>It's not either/or. :)
Well, yes, you could use both at once if you are paranoid.
Lawrence D'Oliveiro
wrote:
> On Sun, 20 Sep 2009 14:17:44 +1200, Lawrence D'Oliveiro
> <l...@geek-central.gen.new_zealand> wrote:
>
>>But you still have the problem of trusting the public key.
>
> In the same way that you have a problem trusting a private key that is
> sent to you somehow.
Private keys must NEVER be disclosed.
Lawrence D'Oliveiro
> Surely you should use encryption that *only* the recipient can decipher.
Not necessarily. Digital signatures can be decrypted by anybody.
> If you make a "public" key available either to everyone ...
But a public key still has to be distributed in a trusted fashion.
Lawrence D'Oliveiro
> On Sun, 20 Sep 2009 22:41:11 +1200, Lawrence D'Oliveiro wrote:
>>
>> But a public key still has to be distributed in a trusted fashion.
>
> The whole point of the "public" key is that it is available to all and
> sundry for use by all and sundry for sending a message exclusively to you
> in a way that nobody else can read without spending a very substantial
> quantity of resources to break your private key - certainly not easily
> read.
But how do people know it's *your* public key?
Stephen Worthington
<l...@geek-central.gen.new_zealand> wrote:
>In message <dqibb5dd3l3mecc38...@4ax.com>, Stephen Worthington
>wrote:
>
>> On Sun, 20 Sep 2009 14:17:44 +1200, Lawrence D'Oliveiro
>> <l...@geek-central.gen.new_zealand> wrote:
>>
>>>But you still have the problem of trusting the public key.
>>
>> In the same way that you have a problem trusting a private key that is
>> sent to you somehow.
>
>Private keys must NEVER be disclosed.
As in private key of a public/private pair, yes. As in the private
key made to send to someone else for a single key encryption, then you
have to disclose the key to them for it to be of any use.
Enkidu
> In message <pan.2009.09...@carnations.com>, Carnations wrote:
>
>> On Sun, 20 Sep 2009 12:15:22 +1200, Lawrence D'Oliveiro wrote:
>>
>>> In message <pan.2009.09...@carnations.com>, Carnations wrote:
>>>
>>>> And yes - I agree - confidential emails should be encrypted from source
>>>> - as should their replies.
>>> Which would be better--public-key or secret-key encryption?
>> Surely you should use encryption that *only* the recipient can decipher.
>
> Not necessarily. Digital signatures can be decrypted by anybody.
>
>> If you make a "public" key available either to everyone ...
>
> But a public key still has to be distributed in a trusted fashion.
>
which you can decypher. It's not in anyone's interests to fiddle with a
public key.
Cheers,
Cliff
--
The Internet is interesting in that although the nicknames may change,
the same old personalities show through.
Enkidu
becomes obvious that the public key was not your public key.
Lawrence D'Oliveiro
> On Sun, 20 Sep 2009 23:25:24 +1200, Lawrence D'Oliveiro wrote:
>
>>> The whole point of the "public" key is that it is available to all and
>>> sundry for use by all and sundry for sending a message exclusively to
>>> you in a way that nobody else can read without spending a very
>>> substantial quantity of resources to break your private key - certainly
>>> not easily read.
>>
>> But how do people know it's *your* public key?
>
> They don't.
Then what's the point?
> But if they use it to encrypt a message and then send it to me, if I
> haven't got the secret key that corresponds with that public, then I won't
> be able to read it eh!!
What if they want to send you a private message? If they use the wrong
public key, then the message falls into the hands of someone it's not
intended for.
What about going the other way--supposing you want to send a sensitive
message, for example an instruction to your bank to pay $X to person Y. If
the public key the bank has corresponds to the private key of someone other
than you, then that person has access to your bank account!
Lawrence D'Oliveiro
wrote:
> On Sun, 20 Sep 2009 18:39:55 +1200, Lawrence D'Oliveiro
> <l...@geek-central.gen.new_zealand> wrote:
>
>>In message <dqibb5dd3l3mecc38...@4ax.com>, Stephen
>>Worthington wrote:
>>
>>> On Sun, 20 Sep 2009 14:17:44 +1200, Lawrence D'Oliveiro
>>> <l...@geek-central.gen.new_zealand> wrote:
>>>
>>>>But you still have the problem of trusting the public key.
>>>
>>> In the same way that you have a problem trusting a private key that is
>>> sent to you somehow.
>>
>>Private keys must NEVER be disclosed.
>
> As in private key of a public/private pair, yes. As in the private
> key made to send to someone else for a single key encryption ...
That's called a "secret key".
Stephen Worthington
<l...@geek-central.gen.new_zealand> wrote:
>In message <pan.2009.09...@carnations.com>, Carnations wrote:
>
>> On Sun, 20 Sep 2009 23:25:24 +1200, Lawrence D'Oliveiro wrote:
>>
>>>> The whole point of the "public" key is that it is available to all and
>>>> sundry for use by all and sundry for sending a message exclusively to
>>>> you in a way that nobody else can read without spending a very
>>>> substantial quantity of resources to break your private key - certainly
>>>> not easily read.
>>>
>>> But how do people know it's *your* public key?
>>
>> They don't.
>
>Then what's the point?
The same point as any attempt at communicating with someone else. You
have to start somewhere. If you phone someone and then arrange to
meet them, you can never know for sure that the person you phoned is
the person who you meet with. At least with public key encryption,
you know that only someone with the matching private key can view your
emails.
>> But if they use it to encrypt a message and then send it to me, if I
>> haven't got the secret key that corresponds with that public, then I won't
>> be able to read it eh!!
>
>What if they want to send you a private message? If they use the wrong
>public key, then the message falls into the hands of someone it's not
>intended for.
And you have the same problem with any new communication with anyone.
You have to take something on trust at some point.
>What about going the other way--supposing you want to send a sensitive
>message, for example an instruction to your bank to pay $X to person Y. If
>the public key the bank has corresponds to the private key of someone other
>than you, then that person has access to your bank account!
Well, I would expect that a public key posted by a bank on their web
site would be the right one to be able to talk to them safely. To
make it extra certain, a sane bank would make the key available only
over HTTPS. If they allowed their web site to be hacked and the key
changed, then they would be liable for any losses caused.
Lawrence D'Oliveiro
wrote:
> On Mon, 21 Sep 2009 10:34:56 +1200, Lawrence D'Oliveiro
> <l...@geek-central.gen.new_zealand> wrote:
>
>>In message <pan.2009.09...@carnations.com>, Carnations wrote:
>>
>>> On Sun, 20 Sep 2009 23:25:24 +1200, Lawrence D'Oliveiro wrote:
>>>
>>>>> The whole point of the "public" key is that it is available to all and
>>>>> sundry for use by all and sundry for sending a message exclusively to
>>>>> you in a way that nobody else can read without spending a very
>>>>> substantial quantity of resources to break your private key -
>>>>> certainly not easily read.
>>>>
>>>> But how do people know it's *your* public key?
>>>
>>> They don't.
>>
>>Then what's the point?
>
> The same point as any attempt at communicating with someone else. You
> have to start somewhere.
That's not how it works. If you know someone, you'll recognize them when you
meet face to face.
> At least with public key encryption, you know that only someone with the
> matching private key can view your emails.
But if you didn't get the public key through a trusted channel, then you
don't know whose private key matches it. You might as well not bother with
encryption at all.
>>What about going the other way--supposing you want to send a sensitive
>>message, for example an instruction to your bank to pay $X to person Y. If
>>the public key the bank has corresponds to the private key of someone
>>other than you, then that person has access to your bank account!
>
> Well, I would expect that a public key posted by a bank on their web
> site would be the right one to be able to talk to them safely.
But this is YOUR public key we're talking about, not that of the bank.
Stephen Worthington
<l...@geek-central.gen.new_zealand> wrote:
>In message <lpfdb553r65dp86mn...@4ax.com>, Stephen Worthington
>wrote:
>
>> On Mon, 21 Sep 2009 10:34:56 +1200, Lawrence D'Oliveiro
>> <l...@geek-central.gen.new_zealand> wrote:
>>
>>>In message <pan.2009.09...@carnations.com>, Carnations wrote:
>>>
>>>> On Sun, 20 Sep 2009 23:25:24 +1200, Lawrence D'Oliveiro wrote:
>>>>
>>>>>> The whole point of the "public" key is that it is available to all and
>>>>>> sundry for use by all and sundry for sending a message exclusively to
>>>>>> you in a way that nobody else can read without spending a very
>>>>>> substantial quantity of resources to break your private key -
>>>>>> certainly not easily read.
>>>>>
>>>>> But how do people know it's *your* public key?
>>>>
>>>> They don't.
>>>
>>>Then what's the point?
>>
>> The same point as any attempt at communicating with someone else. You
>> have to start somewhere.
>
>That's not how it works. If you know someone, you'll recognize them when you
>meet face to face.
If you know them. It is pretty rare to know someone you are emailing
these days.
>> At least with public key encryption, you know that only someone with the
>> matching private key can view your emails.
>
>But if you didn't get the public key through a trusted channel, then you
>don't know whose private key matches it. You might as well not bother with
>encryption at all.
Sigh. You are missing the point. If you do not know someone, and you
are trying to set up secure email with them, then there simply is NO
way to provide a key securely. You have to trust something to start
the process. Now if you want to be as secure as possible, you could
hire a private detective in whatever country your correspondent lives
in to get a report on them. Then you could go and meet them
personally and take hand delivery of their public key. But I doubt
that process is fully secure either, as you do not know them. They
might be government agents running a drug sting, or really good
con-men, and you would not know.
So, the easy way is to initially trust a downloaded public key. That
is what they were invented for. It is the same process as buying
something from a new web site - you do not know if you can trust them.
You have to decide whether to try it out or not. Encryption of the
connection to the web site does not help with the decision to trust
them or not. Similarly, public key encryption of your emails does not
help with the decision to trust the person you are corresponding with
or not. It just makes sure that only someone with the corresponding
private key will be able to read the emails.
>>>What about going the other way--supposing you want to send a sensitive
>>>message, for example an instruction to your bank to pay $X to person Y. If
>>>the public key the bank has corresponds to the private key of someone
>>>other than you, then that person has access to your bank account!
>>
>> Well, I would expect that a public key posted by a bank on their web
>> site would be the right one to be able to talk to them safely.
>
>But this is YOUR public key we're talking about, not that of the bank.
No, we were talking about the bank's public key. You do not have to
make your own public key particularly public when starting secure
communications with someone. You can email it to them along with your
first encrypted email if you like, rather than putting it on your web
site. And you can ask them to email their public key also, if you
prefer that. But keeping public keys relatively private does not help
with security much (it is just another form of security by obscurity,
which is all to often shown to be useless). The public key encryption
technology is designed to be robust with the public keys widely
disclosed.
Lawrence D'Oliveiro
> On Mon, 21 Sep 2009 10:34:56 +1200, Lawrence D'Oliveiro wrote:
>
>>> They don't.
>>
>> Then what's the point?
>
> You tell them that it is your key.
How do you tell them? Face to face?
Lawrence D'Oliveiro
> On Mon, 21 Sep 2009 10:35:20 +1200, Lawrence D'Oliveiro wrote:
>
>>> As in private key of a public/private pair, yes. As in the private key
>>> made to send to someone else for a single key encryption ...
>>
>> That's called a "secret key".
>
> It's called a "private key".
They're not the same. Do you understand the difference? A private key is
NEVER divulged to anybody.
Lawrence D'Oliveiro
> If you like.
The point is, you need a trusted channel for distributing the public key,
you can't simply pick it up anywhere.
Lawrence D'Oliveiro
> On Tue, 22 Sep 2009 11:56:36 +1200, Lawrence D'Oliveiro wrote:
>
>> In message <pan.2009.09...@carnations.com>, Carnations wrote:
>>
>>> On Mon, 21 Sep 2009 10:35:20 +1200, Lawrence D'Oliveiro wrote:
>>>
>>>> In message <24ecb5hhc2745491s...@4ax.com>, Stephen
>>>> Worthington wrote:
>>>>
>>>>> As in the private key made to send to someone else for a single key
>>>>> encryption ...
>>>>>
>>>> That's called a "secret key".
>>>
>>> It's called a "private key".
>>
>> They're not the same. Do you understand the difference? A private key is
>> NEVER divulged to anybody.
>
> Correct.
>
> Duh!!
Then why did you say a "secret key" was called a "private key"?
Enkidu
> In message <pan.2009.09...@carnations.com>, Carnations wrote:
>
>> On Tue, 22 Sep 2009 11:55:56 +1200, Lawrence D'Oliveiro wrote:
>>
>>> In message <pan.2009.09...@carnations.com>, Carnations wrote:
>>>
>>>> On Mon, 21 Sep 2009 10:34:56 +1200, Lawrence D'Oliveiro wrote:
>>>>
>>>>>> They don't.
>>>>> Then what's the point?
>>>> You tell them that it is your key.
>>> How do you tell them? Face to face?
>> If you like.
>
> The point is, you need a trusted channel for distributing the public key,
> you can't simply pick it up anywhere.
>
Bruce Sinclair
>Lawrence D'Oliveiro wrote:
>> In message <pan.2009.09...@carnations.com>, Carnations wrote:
>>> On Tue, 22 Sep 2009 11:55:56 +1200, Lawrence D'Oliveiro wrote:
>>>> In message <pan.2009.09...@carnations.com>, Carnations wrote:
>>>>> On Mon, 21 Sep 2009 10:34:56 +1200, Lawrence D'Oliveiro wrote:
>>>>>
>>>>>>> They don't.
>>>>>> Then what's the point?
>>>>> You tell them that it is your key.
>>>> How do you tell them? Face to face?
>>> If you like.
>>
>> The point is, you need a trusted channel for distributing the public key,
>> you can't simply pick it up anywhere.
> >
>Yes you can. It doesn't matter who gets it.
Quite. That's why it's called "public". :)
Lawrence D'Oliveiro
> On Wed, 23 Sep 2009 11:35:35 +1200, Lawrence D'Oliveiro wrote:
>
>> In message <pan.2009.09...@carnations.com>, Carnations wrote:
>>
>>> On Tue, 22 Sep 2009 11:56:36 +1200, Lawrence D'Oliveiro wrote:
>>>
>>>> In message <pan.2009.09...@carnations.com>, Carnations wrote:
>>>>
>>>>> On Mon, 21 Sep 2009 10:35:20 +1200, Lawrence D'Oliveiro wrote:
>>>>>
>>>>>> In message <24ecb5hhc2745491s...@4ax.com>, Stephen
>>>>>> Worthington wrote:
>>>>>>
>>>>>>> As in the private key made to send to someone else for a single key
>>>>>>> encryption ...
>>>>>>>
>>>>>> That's called a "secret key".
>>>>>
>>>>> It's called a "private key".
>>>>
>>>> They're not the same. Do you understand the difference? A private key
>>>> is NEVER divulged to anybody.
>>>
>>> Correct.
>>>
>>> Duh!!
>>
>> Then why did you say a "secret key" was called a "private key"?
>
> I didn't. I said a private key is a private key.
See above. I was referring to a "secret key", which you said was a "private
key". Why?