a half-baked analysis of the verification chicken-and-egg problem, and request

classic Classic list List threaded Threaded
68 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

a half-baked analysis of the verification chicken-and-egg problem, and request

Joel Rees-2
My understanding of the problem:

(Bear with me. I'm trying not to ramble too much here.)

For catching simple data errors in the download, there is no problem,
of course. The "attacker" is random chance, so downloading the SHA256
file and comparing the checksums should be sufficient.

The probability of an error in the image download being matched by an
error in the checksum file download is pretty close to zero.

However, if we consider the possibility that the image has been
deliberately modified, we must also consider the possibility that the
checksum file has also been deliberately modified. In this case the
probability that the modified image matches the modified checksums is
close to one.

Therefore, for man-in-the-middle attacks, we are presented with a
logical vicious cycle, a problem of whether we trust the chicken first
or the egg, or rather, whether we trust the image first, which contains
the cryptographic key and the verification tool for testing the
checksums, or the checksums themselves first, which can be tested with
the sha256sum tool from some other source.

Out-of-band information is the way to break the vicious cycle, thus the CDs are worth the price.

Now, for the general attack, we can assume that it would be hard enough for a single government, or even several in collusion, to dynamically maintain man-in-the-middle modifications and prevent the developers from noticing at the same time as preventing the receiver from noticing. If checksums don't match, enough people will ask questions, and the attacker's hand is tipped.

For focused attacks, we can posit the interception of a few sets of CDs and DNS poisoning of a few individuals' internet connection. There seems to be very little to do to avoid this.

I downloaded the install CD55.iso and the checksums from a nearby mirror. I also downloaded the checksums from the central server and several other mirrors (somewhere in the US, Africa, South America, Europe, IIRC). And I compared the checksum files with each other, and they matched. So the mirrors agree, and I can assume I'm fairly safe from rogue mirrors.

If I were the target of a focused attack (low probability, but must be considered), the attackers might be filtering my stream and mechanically replacing every query against a known mirror with their altered mirror, with its altered images and checksums. And they would have to be able to intercept my physical CDs, as well.

That's possible, but it's a lot of work for the attackers. And if they attack too many individuals, as I note above, the chance of their hand being tipped rises high enough to be a significant extra cost to them. Thus, this kind of attack has to be limited to a one-shot, carefully coordinated attack, too expensive to use for small game.

So I can download the checksums on separate days, to make it harder for them to maintain the attack successfully, and wait to actually install the system until I've got checksums from several different mirrors, several different times. Downloading multiple copies of the checksums at different times reduces my exposure to man-in-the-middle attacks. Not perfect, but better than nothing.

One suggestion/request, to make it even harder for the man-in-the-middle attack to be successfully employed, could the current checksums be posted in the announcement of the new version?

When those announcements get echoed by magazines or by other bloggers, they could produce copies of the checksums that are going to be much harder for an attacker to catch in its filters. (Might require asking the magazines and bloggers to echo the checksums with the announcements.)

--
Joel Rees <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: a half-baked analysis of the verification chicken-and-egg problem, and request

Theo de Raadt
Checksums?  SHA256 files?  There are no SHA256 files.  Now there are
SHA256.sig files.  You are at least 6 months behind the times.

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/signify.1?query=signify&arch=i386

See the EXAMPLES section.

You can visually verify the (very short) signify keys by finding them
in one or two places -- in /etc/signify/ of previous install, in the
source tree, on twitter or google, or anywhere else you like.  Ask questions
if you see once which disagree.


Then follow the procedure described in EXAMPLES.  This is more than
a checksum.


In any case, please do buy the CDs as an out of band mechanism as
well.  If not enough of them sell, maybe we should consider disabling
the signify mechanism to encourage CD sales....



>My understanding of the problem:
>
>(Bear with me. I'm trying not to ramble too much here.)
>
>For catching simple data errors in the download, there is no problem,
>of course. The "attacker" is random chance, so downloading the SHA256
>file and comparing the checksums should be sufficient.
>
>The probability of an error in the image download being matched by an
>error in the checksum file download is pretty close to zero.
>
>However, if we consider the possibility that the image has been
>deliberately modified, we must also consider the possibility that the
>checksum file has also been deliberately modified. In this case the
>probability that the modified image matches the modified checksums is
>close to one.
>
>Therefore, for man-in-the-middle attacks, we are presented with a
>logical vicious cycle, a problem of whether we trust the chicken first
>or the egg, or rather, whether we trust the image first, which contains
>the cryptographic key and the verification tool for testing the
>checksums, or the checksums themselves first, which can be tested with
>the sha256sum tool from some other source.
>
>Out-of-band information is the way to break the vicious cycle, thus the CDs are worth the price.
>
>Now, for the general attack, we can assume that it would be hard enough for a single government, or even several in collusion, to dynamically maintain man-in-the-middle modifications and prevent the developers from noticing at the same time as preventing the receiver from noticing. If checksums don't match, enough people will ask questions, and the attacker's hand is tipped.
>
>For focused attacks, we can posit the interception of a few sets of CDs and DNS poisoning of a few individuals' internet connection. There seems to be very little to do to avoid this.
>
>I downloaded the install CD55.iso and the checksums from a nearby mirror. I also downloaded the checksums from the central server and several other mirrors (somewhere in the US, Africa, South America, Europe, IIRC). And I compared the checksum files with each other, and they matched. So the mirrors agree, and I can assume I'm fairly safe from rogue mirrors.
>
>If I were the target of a focused attack (low probability, but must be considered), the attackers might be filtering my stream and mechanically replacing every query against a known mirror with their altered mirror, with its altered images and checksums. And they would have to be able to intercept my physical CDs, as well.
>
>That's possible, but it's a lot of work for the attackers. And if they attack too many individuals, as I note above, the chance of their hand being tipped rises high enough to be a significant extra cost to them. Thus, this kind of attack has to be limited to a one-shot, carefully coordinated attack, too expensive to use for small game.
>
>So I can download the checksums on separate days, to make it harder for them to maintain the attack successfully, and wait to actually install the system until I've got checksums from several different mirrors, several different times. Downloading multiple copies of the checksums at different times reduces my exposure to man-in-the-middle attacks. Not perfect, but better than nothing.
>
>One suggestion/request, to make it even harder for the man-in-the-middle attack to be successfully employed, could the current checksums be posted in the announcement of the new version?
>
>When those announcements get echoed by magazines or by other bloggers, they could produce copies of the checksums that are going to be much harder for an attacker to catch in its filters. (Might require asking the magazines and bloggers to echo the checksums with the announcements.)
>
>--
>Joel Rees <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: a half-baked analysis of the verification chicken-and-egg problem, and request

Theo de Raadt
In reply to this post by Joel Rees-2
>One suggestion/request, to make it even harder for the man-in-the-middle attack to be successfully employed, could the current checksums be posted in the announcement of the new version?

http://www.openbsd.org/55.html

    signify(1) pubkeys for this release:
    base: RWRGy8gxk9N9314J0gh9U02lA7s8i6ITajJiNgxQOndvXvM5ZPX+nQ9h
    fw: RWTdVOhdk5qyNktv0iGV6OpaVfogGxTYc1bbkaUhFlExmclYvpJR/opO
    pkg: RWQQC1M9dhm/tja/ktitJs/QVI1kGTQr7W7jtUmdZ4uTp+4yZJ6RRHb5

For the upcoming 5.6 release (few months yet), the keys are already
included in your 5.5 install, or you can find them in your /etc/signify
directory.  Or, check http://www.openbsd.org/56.html (warning: incomplete)

    signify(1) pubkeys for this release:
    base: RWR0EANmo9nqhpPbPUZDIBcRtrVcRwQxZ8UKGWY8Ui4RHi229KFL84wV
    fw: RWT4e3jpYgSeLYs62aDsUkcvHR7+so5S/Fz/++B859j61rfNVcQTRxMw
    pkg: RWSPEf7Vpp2j0PTDG+eLs5L700nlqBFzEcSmHuv3ypVUEOYwso+UucXb

In fact the snapshots available since about a month ago already include
the public keys for the 5.7 release next May....

Reply | Threaded
Open this post in threaded view
|

Re: [Bulk] Re: a half-baked analysis of the verification chicken-and-egg problem, and request

Kevin Chadwick-2
In reply to this post by Theo de Raadt
previously on this list Theo de Raadt contributed:

> source tree,

Whose fingerprints are available on the website, many of which for years
and are probably in googles cache available over ssl and many other
corners of the web.

> on twitter or google, or anywhere else you like.  Ask questions
> if you see once which disagree.
>
>
> Then follow the procedure described in EXAMPLES.  This is more than
> a checksum.
>
>
> In any case, please do buy the CDs as an out of band mechanism as
> well.  If not enough of them sell, maybe we should consider disabling
> the signify mechanism to encourage CD sales....

It has occurred to me that you have been very good in terms of not
tying the keys in any way to the buying of cds for each
release/snapshot. I donate what I can rather than buy cd's as it is more
efficient but I guess the money goes to a different place. I do hope
there hasn't been a drop/sharp drop in cd sales? I guess any switch
to donations may be masked by other fundraising?

--
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
_______________________________________________________________________

Reply | Threaded
Open this post in threaded view
|

Re: [Bulk] Re: a half-baked analysis of the verification chicken-and-egg problem, and request

Eric Furman-3
On Wed, Aug 13, 2014, at 04:47 AM, Kevin Chadwick wrote:
> It has occurred to me that you have been very good in terms of not
> tying the keys in any way to the buying of cds for each
> release/snapshot. I donate what I can rather than buy cd's as it is more
> efficient but I guess the money goes to a different place. I do hope
> there hasn't been a drop/sharp drop in cd sales? I guess any switch
> to donations may be masked by other fundraising?

The most absolutely best way any one can contribute to OBSD
is to BUY CD'S. Buy some cd's and then buy some more.
Buy them for the stickers. Buy them because they fund OBSD.
Without cd sales OBSD would cease to exist.
It is as simple as that. So, BUY CD'S!
That is worth repeating;
Without CD sales OpenBSD will cease to exist. PERIOD.
Contrary to what a lot of you assholes think
NOTHING IS FOR FREE.
ELECTRICITY COSTS MONEY.
FOOD COSTS MONEY
BEER COSTS MONEY.
BUY CD'S
thank you for your attention.

Reply | Threaded
Open this post in threaded view
|

Re: a half-baked analysis of the verification chicken-and-egg problem, and request

Carlin Bingham
In reply to this post by Theo de Raadt
On Wed, 13 Aug 2014, at 11:38 AM, Theo de Raadt wrote:

> >One suggestion/request, to make it even harder for the man-in-the-middle attack to be successfully employed, could the current checksums be posted in the announcement of the new version?
>
> http://www.openbsd.org/55.html
>
>     signify(1) pubkeys for this release:
>     base: RWRGy8gxk9N9314J0gh9U02lA7s8i6ITajJiNgxQOndvXvM5ZPX+nQ9h
>     fw: RWTdVOhdk5qyNktv0iGV6OpaVfogGxTYc1bbkaUhFlExmclYvpJR/opO
>     pkg: RWQQC1M9dhm/tja/ktitJs/QVI1kGTQr7W7jtUmdZ4uTp+4yZJ6RRHb5
>
> For the upcoming 5.6 release (few months yet), the keys are already
> included in your 5.5 install, or you can find them in your /etc/signify
> directory.  Or, check http://www.openbsd.org/56.html (warning:
> incomplete)
>
>     signify(1) pubkeys for this release:
>     base: RWR0EANmo9nqhpPbPUZDIBcRtrVcRwQxZ8UKGWY8Ui4RHi229KFL84wV
>     fw: RWT4e3jpYgSeLYs62aDsUkcvHR7+so5S/Fz/++B859j61rfNVcQTRxMw
>     pkg: RWSPEf7Vpp2j0PTDG+eLs5L700nlqBFzEcSmHuv3ypVUEOYwso+UucXb
>
> In fact the snapshots available since about a month ago already include
> the public keys for the 5.7 release next May....
>

Now checkout the keys in /src/etc/signify/ from cvs over ssh, check that
the fingerprint of the cvs server matches what is on the website (and/or
in the various caches), and compare the keys match what was posted. And
as mailing list posts are mirrored on many archive sites, compare that
the various archives agree with what keys were posted.

And once you have a 5.5 that you're confident is legitimate, every
subsequent release can be verified using the keys from it, and you will
have a chain of trust.

Reply | Threaded
Open this post in threaded view
|

Re: a half-baked analysis of the verification chicken-and-egg problem, and request

Carlin Bingham
In reply to this post by Theo de Raadt
On Wed, 13 Aug 2014, at 11:38 AM, Theo de Raadt wrote:

> >One suggestion/request, to make it even harder for the man-in-the-middle attack to be successfully employed, could the current checksums be posted in the announcement of the new version?
>
> http://www.openbsd.org/55.html
>
>     signify(1) pubkeys for this release:
>     base: RWRGy8gxk9N9314J0gh9U02lA7s8i6ITajJiNgxQOndvXvM5ZPX+nQ9h
>     fw: RWTdVOhdk5qyNktv0iGV6OpaVfogGxTYc1bbkaUhFlExmclYvpJR/opO
>     pkg: RWQQC1M9dhm/tja/ktitJs/QVI1kGTQr7W7jtUmdZ4uTp+4yZJ6RRHb5
>
> For the upcoming 5.6 release (few months yet), the keys are already
> included in your 5.5 install, or you can find them in your /etc/signify
> directory.  Or, check http://www.openbsd.org/56.html (warning:
> incomplete)
>
>     signify(1) pubkeys for this release:
>     base: RWR0EANmo9nqhpPbPUZDIBcRtrVcRwQxZ8UKGWY8Ui4RHi229KFL84wV
>     fw: RWT4e3jpYgSeLYs62aDsUkcvHR7+so5S/Fz/++B859j61rfNVcQTRxMw
>     pkg: RWSPEf7Vpp2j0PTDG+eLs5L700nlqBFzEcSmHuv3ypVUEOYwso+UucXb
>
> In fact the snapshots available since about a month ago already include
> the public keys for the 5.7 release next May....
>

Are there plans to get openbsd.org serving over SSL? That would help a
bit in trusting the keys posted to the website.

Reply | Threaded
Open this post in threaded view
|

Re: a half-baked analysis of the verification chicken-and-egg problem, and request

Giancarlo Razzolini-3
On 13-08-2014 09:04, Carlin Bingham wrote:
> Are there plans to get openbsd.org serving over SSL? That would help a
> bit in trusting the keys posted to the website.
>
No, it wouldn't. If we go down that path, DNSSEC, with all it's problems
is better than SSL for this. You can get free ssl certificates these
days, so the cost isn't the issue here. I do many things that the OP
said, such as downloading the sig's from different mirrors, using
different internet connections at different times. And even now that
there are the pub keys for the next release on the install, I'll keep
doing this, just to be sure.

Cheers,

--
Giancarlo Razzolini
GPG: 4096R/77B981BC

[demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]

Reply | Threaded
Open this post in threaded view
|

Re: a half-baked analysis of the verification chicken-and-egg problem, and request

Carlin Bingham
On Thu, 14 Aug 2014, at 12:38 AM, Giancarlo Razzolini wrote:

> On 13-08-2014 09:04, Carlin Bingham wrote:
> > Are there plans to get openbsd.org serving over SSL? That would help a
> > bit in trusting the keys posted to the website.
> >
> No, it wouldn't. If we go down that path, DNSSEC, with all it's problems
> is better than SSL for this. You can get free ssl certificates these
> days, so the cost isn't the issue here. I do many things that the OP
> said, such as downloading the sig's from different mirrors, using
> different internet connections at different times. And even now that
> there are the pub keys for the next release on the install, I'll keep
> doing this, just to be sure.
>
> Cheers,
>
> --
> Giancarlo Razzolini
> GPG: 4096R/77B981BC
>

Of course, but doing all that in addition to getting the keys over SSL
is better than doing all that and not getting the keys over SSL.

Reply | Threaded
Open this post in threaded view
|

Re: a half-baked analysis of the verification chicken-and-egg problem, and request

Giancarlo Razzolini-3
On 13-08-2014 09:54, Carlin Bingham wrote:
> Of course, but doing all that in addition to getting the keys over SSL
> is better than doing all that and not getting the keys over SSL.
>
I did sent this same e-mail you sent almost a year ago. We have signify
now. Things have changed. There is always, and always will be the
problem of trust. Or, in this case, the initial trust. I don't see
OpenBSD adding SSL nor DNSSEC.

Cheers,

--
Giancarlo Razzolini
GPG: 4096R/77B981BC

[demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]

Reply | Threaded
Open this post in threaded view
|

Re: [Bulk] Re: a half-baked analysis of the verification chicken-and-egg problem, and request

Kevin Chadwick-2
In reply to this post by Giancarlo Razzolini-3
previously on this list Giancarlo Razzolini contributed:

> > Are there plans to get openbsd.org serving over SSL? That would help a
> > bit in trusting the keys posted to the website.
> >  
> No, it wouldn't. If we go down that path, DNSSEC, with all it's problems
> is better than SSL for this. You can get free ssl certificates these
> days, so the cost isn't the issue here. I do many things that the OP
> said, such as downloading the sig's from different mirrors, using
> different internet connections at different times. And even now that
> there are the pub keys for the next release on the install, I'll keep
> doing this, just to be sure.

Perhaps we should ask debian or arch to ask gnupg.orgs keyserver to use
a CA signed cert but of course they wouldn't and offer a self-signed I
guess for political reasons or not to trip up those who don't
understand the issues and perhaps that is true for OpenBSD and whilst
it could be an extra check on the ssh fingerprints, might it make people
lazy and actually less secure. OpenBSD is actually now probably the most
secure open source project in this regard even initially now with so
many sources for initial verification (even ip whois records of ssh
servers) and re-verification and especially considering

The CD's are managed by Theo himself!

To top it all off past threads have shown that Arches build system and
debians packages that can include binary uploads are alarmingly
questionable even when signed with a known valid key.

--
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
_______________________________________________________________________

Reply | Threaded
Open this post in threaded view
|

Re: a half-baked analysis of the verification chicken-and-egg problem, and request

Alexander Hall
In reply to this post by Carlin Bingham
On August 13, 2014 2:04:14 PM CEST, Carlin Bingham <[hidden email]> wrote:

>On Wed, 13 Aug 2014, at 11:38 AM, Theo de Raadt wrote:
>> >One suggestion/request, to make it even harder for the
>man-in-the-middle attack to be successfully employed, could the current
>checksums be posted in the announcement of the new version?
>>
>> http://www.openbsd.org/55.html
>>
>>     signify(1) pubkeys for this release:
>>     base: RWRGy8gxk9N9314J0gh9U02lA7s8i6ITajJiNgxQOndvXvM5ZPX+nQ9h
>>     fw: RWTdVOhdk5qyNktv0iGV6OpaVfogGxTYc1bbkaUhFlExmclYvpJR/opO
>>     pkg: RWQQC1M9dhm/tja/ktitJs/QVI1kGTQr7W7jtUmdZ4uTp+4yZJ6RRHb5
>>
>> For the upcoming 5.6 release (few months yet), the keys are already
>> included in your 5.5 install, or you can find them in your
>/etc/signify
>> directory.  Or, check http://www.openbsd.org/56.html (warning:
>> incomplete)
>>
>>     signify(1) pubkeys for this release:
>>     base: RWR0EANmo9nqhpPbPUZDIBcRtrVcRwQxZ8UKGWY8Ui4RHi229KFL84wV
>>     fw: RWT4e3jpYgSeLYs62aDsUkcvHR7+so5S/Fz/++B859j61rfNVcQTRxMw
>>     pkg: RWSPEf7Vpp2j0PTDG+eLs5L700nlqBFzEcSmHuv3ypVUEOYwso+UucXb
>>
>> In fact the snapshots available since about a month ago already
>include
>> the public keys for the 5.7 release next May....
>>
>
>Are there plans to get openbsd.org serving over SSL? That would help a
>bit in trusting the keys posted to the website.

How did you download your browser? Can you trust all certs it uses? Etc etc...:-p

So many chickens and eggs here.

Reply | Threaded
Open this post in threaded view
|

Re: a half-baked analysis of the verification chicken-and-egg problem, and request

Giancarlo Razzolini-3
On 13-08-2014 11:36, Alexander Hall wrote:
> How did you download your browser? Can you trust all certs it uses? Etc
etc...:-p
It can't. Just see the Turktrust/Google case.
>
> So many chickens and eggs here.
Since we are at this, how can you trust your operating system? Your
hardware? Everyone need to trust somebody else at some point, otherwise
we wouldn't be here. On the other hand, a little bit of paranoia, never
hurt.

Cheers,

--
Giancarlo Razzolini
GPG: 4096R/77B981BC

[demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]

Reply | Threaded
Open this post in threaded view
|

Re: [Bulk] Re: a half-baked analysis of the verification chicken-and-egg problem, and request

Giancarlo Razzolini-3
In reply to this post by Kevin Chadwick-2
On 13-08-2014 10:55, Kevin Chadwick wrote:
> Perhaps we should ask debian or arch to ask gnupg.orgs keyserver to use
> a CA signed cert but of course they wouldn't and offer a self-signed I
> guess for political reasons or not to trip up those who don't
> understand the issues and perhaps that is true for OpenBSD and whilst
> it could be an extra check on the ssh fingerprints, might it make people
> lazy and actually less secure.
Today there is never a need for self-signed certs. You can get them for
free, there's no excuse. For ssh fingerprints there are SSHFP records.
With DNSSEC, they can be better checked. But I agree with you that it
might make people lazy.
>  OpenBSD is actually now probably the most
> secure open source project in this regard even initially now with so
> many sources for initial verification (even ip whois records of ssh
> servers) and re-verification and especially considering
With signify, OpenBSD managed to give the same level of trust, specially
on the packages, as the linux distros with their gpged apt. But better.
Signify is way simpler. On the verification side, OpenBSD have lots of
mirrors, but if your dns is compromised you can't trust your whois.
>
>
> The CD's are managed by Theo himself!
This is great. But if you're being targeted, your CD might be
intercepted. This is why you should use them plus the internet for
checking things.
>
> To top it all off past threads have shown that Arches build system and
> debians packages that can include binary uploads are alarmingly
> questionable even when signed with a known valid key.
Their security track record isn't that great.

Cheers,

--
Giancarlo Razzolini
GPG: 4096R/77B981BC

[demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]

Reply | Threaded
Open this post in threaded view
|

Re: a half-baked analysis of the verification chicken-and-egg problem, and request

Lars
In reply to this post by Giancarlo Razzolini-3
On 13.08.2014 17:11, Giancarlo Razzolini wrote:

> On 13-08-2014 11:36, Alexander Hall wrote:
>> How did you download your browser? Can you trust all certs it uses?
>> Etc
> etc...:-p
> It can't. Just see the Turktrust/Google case.
>>
>> So many chickens and eggs here.
> Since we are at this, how can you trust your operating system? Your
> hardware? Everyone need to trust somebody else at some point, otherwise
> we wouldn't be here. On the other hand, a little bit of paranoia, never
> hurt.

To be honest, I find those discussions rather bizarr and yet they seem
to pop up more often.
With signify OpenBSD developers have created a tool that can give you a
reasonable amount of certainty that the software you are using is the
one that has been written and released by the OpenBSD team. Most Linux
distros or other projects are not providing more ways to have that kind
of reassurance and yet people start questioning every single bit that is
coming from OpenBSD and demand proove.

Next thing is that they want Theo to carve the bits into his
HDD-platters because they don't trust the controller software. *Please*.
I am all for paranoia and usually I am also seeing the bad things first
- but sometimes what is asked for is far beyond reasonable and doable.

If people would really think their demands through to the end and
understand what they are asking for - they would shutdown their
computers, trash them for good and start a woodworking business or
growing plants instead.

Please get back to the ground and be reasonable. What we now have is
better from what we had last year. So progress is being made and I want
to thank the team for that. If there is something to improve on, I am
certain they will implement it if there is a real benefit.
I, for my part have decided to trust at least this team. As you said, at
some point we have to trust somebody, because nobody needs so many
woodworkers.

Thanks

Lars

Reply | Threaded
Open this post in threaded view
|

Re: [Bulk] Re: [Bulk] Re: a half-baked analysis of the verification chicken-and-egg problem, and request

Kevin Chadwick-2
In reply to this post by Giancarlo Razzolini-3
On Wed, 13 Aug 2014 12:19:40 -0300
Giancarlo Razzolini wrote:

> Today there is never a need for self-signed certs. You can get them for
> free, there's no excuse.

Tell that to gnupg.org, as I say political... but useful going forward
but there are only a few keyservers.

Also if you have a secure method to share the fingerprint then
self-signed are more secure. Personally I would like someone, perhaps
a major browser to create a service where we can login and submit our
fingerprint and get a password which they match to a password installed
at the root of your website in a file like .sslcheck over ssl and so
matching the password and fingerprint. If a rogue has write ability you
can't trust the ssl anyway and this keeps it to the basic elements
rather than introducing other potential insecurities like DNSSEC would.
I am assuming an attacker would find it very hard to create a key to
match a fingerprint but could be wrong?

I also find myself debating with using a CA signed cert with STARTTLS
as it can too easily offer a false sense of security due to downgrade
attacks.

Reply | Threaded
Open this post in threaded view
|

Re: [Bulk] Re: [Bulk] Re: a half-baked analysis of the verification chicken-and-egg problem, and request

Theo de Raadt
In reply to this post by Joel Rees-2
> On Wed, 13 Aug 2014 12:19:40 -0300
> Giancarlo Razzolini wrote:
>
> > Today there is never a need for self-signed certs. You can get them for
> > free, there's no excuse.
>
> Tell that to gnupg.org, as I say political... but useful going forward
> but there are only a few keyservers.
>
> Also if you have a secure method to share the fingerprint then
> self-signed are more secure. Personally I would like someone, perhaps
> a major browser to create a service where we can login and submit our
> fingerprint and

oh, I suppose because everything is much safer better when you add half
a million lines of browser code to the mix.

Insane.

Reply | Threaded
Open this post in threaded view
|

Re: [Bulk] Re: [Bulk] Re: [Bulk] Re: a half-baked analysis of the verification chicken-and-egg problem, and request

Kevin Chadwick-2
On Wed, 13 Aug 2014 11:12:21 -0600
Theo de Raadt wrote:

> > Also if you have a secure method to share the fingerprint then
> > self-signed are more secure. Personally I would like someone, perhaps
> > a major browser to create a service where we can login and submit our
> > fingerprint and  
>
> oh, I suppose because everything is much safer better when you add half
> a million lines of browser code to the mix.
>
> Insane.

I meant for improving the web by avoiding CA's though not for OpenBSD
but yeah, wrong list, sorry.

Reply | Threaded
Open this post in threaded view
|

Re: [Bulk] Re: [Bulk] Re: [Bulk] Re: a half-baked analysis of the verification chicken-and-egg problem, and request

Theo de Raadt
In reply to this post by Joel Rees-2
> > > Also if you have a secure method to share the fingerprint then
> > > self-signed are more secure. Personally I would like someone, perhaps
> > > a major browser to create a service where we can login and submit our
> > > fingerprint and  
> >
> > oh, I suppose because everything is much safer better when you add half
> > a million lines of browser code to the mix.
> >
> > Insane.
>
> I meant for improving the web by avoiding CA's though not for OpenBSD
> but yeah, wrong list, sorry.

Yeah, and "world peace".

Reply | Threaded
Open this post in threaded view
|

Re: [Bulk] Re: a half-baked analysis of the verification chicken-and-egg problem, and request

Worik Stanton
In reply to this post by Eric Furman-3
On 13/08/14 22:13, Eric Furman wrote:
[snip]>
> The most absolutely best way any one can contribute to OBSD
> is to BUY CD'S. Buy some cd's and then buy some more.
> Buy them for the stickers. Buy them because they fund OBSD.
> Without cd sales OBSD would cease to exist.
> It is as simple as that. So, BUY CD'S!
> That is worth repeating;
> Without CD sales OpenBSD will cease to exist. PERIOD.
> Contrary to what a lot of you assholes think

I would rather have a 5.5 T'shirt.

I am new and when I am ready I will be back here asking questions but
for now, I do not want a CD (totally useless to me) but a T'shirt would
be cool.  It would cover my nakedness.

Looking on http://www.openbsd.org/tshirts.html I can see no 5.5 T'shirt.

Actually given that today I am at home because of snow on the  Lieth
Saddle a 5.5 merino hoodie would be best. It would cover my nakedness
and keep me warm(er)

> NOTHING IS FOR FREE.

yea
Worik

--
Why is the legal status of chardonnay different to that of cannabis?
       [hidden email] 021-1680650, (03) 4821804
                          Aotearoa (New Zealand)

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1234