Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Kevin Chadwick]

> It's not so much about replacing keys which aren't strong enough (and
> actually you can just replace the old key+cert in that case), it's
> about dealing with compromised keys.
> 
> Certificate revocation is a disaster area. CRLs are often not checked
> at all (letsencrypt aren't even generating CRL entries for end-user
> certs - startssl will do but they charge for them, even for free
> certs). 

Ya I found out when I tried to upgrade to sha256 ;) and found I had to
wait for the current ones to expire.

> OCSP is probably checked more often in browsers than CRLs
> but fails open in some cases (and has terrible UI in others) and
> again isn't used universally - keeping certificate lifetimes short
> is a useful way to limit the damage that can be done by a compromised
> key. (and if letsencrypt *were* to start doing CRLs for revoked
> end-user certs, keeping lifetimes short would also limit the file
> size of the CRL).

Well atleast that's a more sensible reason. Not sure I like the idea of
a non priviledge seperated internet connecting script accessing the key
every few months (it is open source though), potentially nullifying
effort by some daemons/LibreSSL in that area. Despite joining the beta,
I haven't had time to look into the tools yet. I guess/hope it wouldn't
be hard to have a system user with key file access that provides a CSR
to another chrooted system user that downloads the new certificate. ftp
is pledged I believe in the next release which will add some belts and
braces I guess too.



-- 

KISSIS - Keep It Simple So It's Securable

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Stuart Henderson]

On 2015-12-12, Kevin Chadwick  wrote:
>> > and have to keep changing the cert every year.  
>> 
>> Your certificate cycling process should be automated, and it should
>> happen more frequently than once a year.
>
> Complete nonsense
>
> firstly and not a major point but you may have greater security than
> automating key changes and secondly the only reason you may want to is
> if you believe your key is not strong enough, in which case use a
> stronger key. It has *little* to do with time really but more to do with
> the amount of traffic the key has been used for and whether PFS has
> solely been used.

It's not so much about replacing keys which aren't strong enough (and
actually you can just replace the old key+cert in that case), it's
about dealing with compromised keys.

Certificate revocation is a disaster area. CRLs are often not checked
at all (letsencrypt aren't even generating CRL entries for end-user
certs - startssl will do but they charge for them, even for free
certs). OCSP is probably checked more often in browsers than CRLs
but fails open in some cases (and has terrible UI in others) and
again isn't used universally - keeping certificate lifetimes short
is a useful way to limit the damage that can be done by a compromised
key. (and if letsencrypt *were* to start doing CRLs for revoked
end-user certs, keeping lifetimes short would also limit the file
size of the CRL).

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Daniel Ouellet]

> Secondly, this whole thread should have ended long ago.

So why you keep it going then.

Let it die please

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Joel Rees]

On Sun, Dec 13, 2015 at 5:00 PM, Daniel Ouellet  wrote:
>> Secondly, this whole thread should have ended long ago.
>
> So why you keep it going then.
>
> Let it die please

Flame wars are educational, for readers with an open mind.

And I think I'll air my own two armpits, off-list:

http://free-is-not-free.blogspot.jp/2015/12/encrypt-everything-or-maybe-not.html

I didn't even begin to cover everything that has been mentioned in
this thread, but I think it might help get those who want to use https
wall-to-wall to think twice and recognize that there are other things
that need attention first. Or maybe not, I tend to think I'm smarter
than I am sometimes.

For those who are concerned about the keys, it has been mentioned
several times, but the best way to get meaningful confidence in the
published keys is to buy the CDs and then check the keys found there
against multiple mirrors. You're going to have to be really valuable
to the NSA or some other well-funded group in your area for them to be
able to filter every mirror you can find.

If you need to, go to a random netcafe or other place and check from there, too.

-- 
Joel Rees

Be careful when you look at conspiracy.
Arm yourself with knowledge of yourself, as well:
http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Michael McConville]

Joel Rees wrote:
> Daniel Ouellet wrote:
> > > Secondly, this whole thread should have ended long ago.
> >
> > So why you keep it going then.
> >
> > Let it die please
> 
> Flame wars are educational, for readers with an open mind.

Flame wars and crypto speculation also make a lot of noise and drive
more focused readers off the list. See the misc-like list of a common
anonymity network for a prime example of this.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Joel Rees]

On Mon, Dec 14, 2015 at 11:00 AM, Michael McConville  wrote:
> Joel Rees wrote:
>> Daniel Ouellet wrote:
>> > > Secondly, this whole thread should have ended long ago.
>> >
>> > So why you keep it going then.
>> >
>> > Let it die please
>>
>> Flame wars are educational, for readers with an open mind.
>
> Flame wars and crypto speculation also make a lot of noise and drive
> more focused readers off the list. See the misc-like list of a common
> anonymity network for a prime example of this.

That's why I'm suggesting the open mind part.

And the think first, and rant in your own blog if you have to part.
Especially if you want to speculate.

(It's easier to edit/delete/tag-as-too-wild-to-take-seriously a post
to your own blog than a post to a mailing list.)

-- 
Joel Rees

Be careful when you look at conspiracy.
Arm yourself with knowledge of yourself, as well:
http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[ludovic coues]

2015-12-13 7:17 GMT+01:00 Delan Azabani :
> On Sun, Dec 13, 2015 at 6:28 AM, Kevin Chadwick  wrote:
>> On a low traffic site it already annoys me that I have to change it
>> once per year with startSSL.
>
> This is what the tooling provided by Let's Encrypt is designed to
> solve. It shouldn't be hard to issue new certificates, and for many
> applications, the fact that issuing them is a manual process results
> in more downtime when a certificate is compromised.
>

I'll give my 2 cents,

First, the author of the Let's Encrypt tool say himself people are
perfectly right to not trust a random script downloaded from the
internet. Their tools should be seen as an example, not the only true
way of doing things.

Secondly, this whole thread should have ended long ago.
It have been mentioned a couple of times. The main outcome of https is
to make caching impossible. It introduce a non trivial computational
cost for serving every file. Remember, OpenBSD is no facebook. It
serve static file from cache, not the output of a script.
There is a lot of whining about refusing https despite it being a
mitigation technique. Would you accept a mitigation technique making
your favorite OS half as slow and consuming twice as much power ? I
don't think so.

Signify exist for integrity. You can get an initial key with the CD.
The CD looks cool on a shelf, comes with nice artwork, helps pay theo
bills and is way harder to tamper than a letter. Who talked about
fiendlish difficulty ?
VPN is a better tool for anonymity. https doesn't hide your DNS query
or the domain you are connecting to. All the bad guy have to search on
the site which page have the same length as the one you downloaded. If
done right, VPN will hide who is downloading the file and put the
burden away from the OpenBSD project.

-- 

Cordialement, Coues Ludovic
+336 148 743 42

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Delan Azabani]

On Sun, Dec 13, 2015 at 6:28 AM, Kevin Chadwick  wrote:
> On a low traffic site it already annoys me that I have to change it
> once per year with startSSL.

This is what the tooling provided by Let's Encrypt is designed to
solve. It shouldn't be hard to issue new certificates, and for many
applications, the fact that issuing them is a manual process results
in more downtime when a certificate is compromised.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Delan Azabani]

On Sat, Dec 12, 2015 at 7:11 PM, Constantine A. Murenin
 wrote:
> once you give in to https once, you're hooked

You're only hooked if you use HSTS.

> and have to keep paying someone every year,

There are at least three CAs that provide free certificates, and one
of those is Let's Encrypt.

> and have to keep changing the cert every year.

Your certificate cycling process should be automated, and it should
happen more frequently than once a year.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Constantine A. Murenin]

On 11 December 2015 at 03:58, Kamil Cholewiński  wrote:
>> The official CD set contains the signify keys for that release and the
>> next one.  Once you have a known good copy of one set, you can always
obtain
>> future ones securely.
>>
>> You don't even need to use the CD set to install, just as a way of
obtaining
>> the signify keys with a high degree of confidence.
>
> This is the real thing bothering me. I don't even have a CD drive
> available, and I was about to ask if it would be possible to get the
> signify keys via paper mail in exchange for a donation. But both paper
> and CDs can be intercepted and tampered with (with some effort).
>
>> I currently just assume they are correct because it'd be enormously
>> complex to spoof the entire OpenBSD distribution, but I souldn't have
>> to rely on "security through effort involved".
>
> Exactly, and this is a problem with the CDs too. There's currently no
> way to securely bootstrap the chain of trust. HTTPS is a way to do that.

LOL.  Maybe you should read this:

http://marc.info/?l=openbsd-bugs=138445221329747=2

Or take a look at the full list of CAs in your browser.

>
> Yes, we would have to rely on third parties (CAs). It can be optional
> (so that a text browser from an ancient unsupported release can still

Thing is, in https land, a "downgrade" is considered a serious attack,
not a backwards-compatibility feature.

If the browser fails to load https://example.org/, it will not even
suggest you go to the http://example.org/ version.

And what happens when someone gets their web-site onto https?  People
start linking to the https version, so, legacy devices/releases may no
longer be capable of just following the web of links.  (So much for
World Wide Web!)

> access plain HTTP version fine). It can be just a single page like
> keys.openbsd.org so that there are few extra computing resources used.
> It doesn't have to be Let's Encrypt - heck, I'm willing to go to
> RapidSSL or whoever and pay for it myself if someone can give me a CSR
> and assist with domain validation.

Yes, and once you give in to https once, you're hooked and have to
keep paying someone every year, and have to keep changing the cert
every year.

C.

>
> K.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Andy Bradford]

Thus said Tati Chevron on Fri, 11 Dec 2015 13:16:23 +:

> On the other hand, if somebody  actually received a fake OpenBSD CD in
> the mail, and it was discovered, it  would be a huge news story within
> the IT industry. A bad download, much less so.

My OpenBSD  5.7 CD arrived  with a green  label affixed to  the shipping
packaging  that claimed  it had  been inspected  by some  U.S.A. customs
department. It had actually been opened and resealed and the green label
placed on it to inform me of said tampering.

Did anything change? Is this a fake  CD? Who knows. I do know that there
was an extra CD in the shipment by The OpenBSD Store, apparently because
there were problems with first stamping of the CD.

Hopefully signify will protect in this case.

Andy
-- 
TAI64 timestamp: 4000566c62a4

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Kevin Chadwick]

> > and have to keep changing the cert every year.  
> 
> Your certificate cycling process should be automated, and it should
> happen more frequently than once a year.

Complete nonsense

firstly and not a major point but you may have greater security than
automating key changes and secondly the only reason you may want to is
if you believe your key is not strong enough, in which case use a
stronger key. It has *little* to do with time really but more to do with
the amount of traffic the key has been used for and whether PFS has
solely been used.

On a low traffic site it already annoys me that I have to change it
once per year with startSSL.

-- 

KISSIS - Keep It Simple So It's Securable

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Kevin Chadwick]

> > I would consider signify keys printed on CDs and copied across several
> > web sites safer than trusting the hundreds of CA certs shipped with a
> > standard web browser.  
> 
> Didn't we just established that with HPKP you can disregard the CA
> completely? At least if you trust your fist access to the site. But I
> think this thread followed its course, lets move on.

Xombrero does that by caching certs ;) I'd hardly call it disregarding
the CA myself, makes it sound much more progressive than it is!

-- 

KISSIS - Keep It Simple So It's Securable

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Stefan Sperling]

On Fri, Dec 11, 2015 at 11:58:17AM +0100, Thijs van Dijk wrote:
> On 11 December 2015 at 05:51, Andy Bradford 
> wrote:
> 
> > If one wants privacy on a website then more is required than just HTTPS.
> >
> 
> Right. *I* just want a reasonable (256-bit) guarantee that the signify keys
> on my screen are the ones the OpenBSD authors intended me to see.
> 
> I currently just assume they are correct because it'd be enormously complex
> to spoof the entire OpenBSD distribution, but I souldn't have to rely on
> "security through effort involved".

I would consider signify keys printed on CDs and copied across several
web sites safer than trusting the hundreds of CA certs shipped with a
standard web browser.

Instead of verifying signify keys you'd now have to keep a copy of
openbsd.org's SSL cert fingerprint and keep track of that as it changes.
And it won't conventiently change in lock step with OpenBSD's release
schedule like signify keys do.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Tati Chevron]

On Fri, Dec 11, 2015 at 11:58:17AM +0100, Thijs van Dijk wrote:

On 11 December 2015 at 05:51, Andy Bradford 
wrote:


If one wants privacy on a website then more is required than just HTTPS.



Right. *I* just want a reasonable (256-bit) guarantee that the signify keys
on my screen are the ones the OpenBSD authors intended me to see.


The official CD set contains the signify keys for that release and the
next one.  Once you have a known good copy of one set, you can always obtain
future ones securely.

You don't even need to use the CD set to install, just as a way of obtaining
the signify keys with a high degree of confidence.

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Constantine A. Murenin]

On 8 December 2015 at 19:26, Anthony J. Bentley  wrote:
> Giancarlo Razzolini writes:
>> One of the main benefits of the TLS wouldn't only be to render
>> impossible for anyone to know which pages you're accessing on the site,
>> but also the fact that we would get a little more security getting the
>> SSH fingerprints for the anoncvs servers. Having them in clear text as
>> they are today, isn't very secure.
>
> Another attack currently possible against www.openbsd.org is changing
> the https://openbsdstore.com links to http://openbsdstore.com, and
> running sslstrip on that. Or the PayPal links...

For real!  And yet another attack currently possible against
www.openbsd.org is being able to view the web-site from any OpenBSD
release, even the early ones that did include lynx in base
(http://mdoc.su/OpenBSD-2.3/lynx.1), yet are surely missing not only
TLSv1.2 (if not OpenSSL in the first place!), but the requisite CA
entries in their corresponding cert.pem file as well (that is, if such
file was even present).

And if you're in Kazakhstan, it's also possible to view
www.openbsd.org without any issues or security warnings, and will
continue being so even after 2016-01-01 when the new telecommunication
directive takes force.  (Or was the feature to ignore invalid
certificates already added to lynx nowadays?)

And another one is a global web-site defacing if the certificate
signing request infrastructure, with a client that is designed to run
on your web-server with the web-server privileges by LetsEncrypt, and
must execute at least once every 3 months (if not more often, as their
plan is to decrease cert validity to be even shorter than 3 months)
turns out to contain an exploitable vulnerability.  Wait, that's one
not possible!  (At least not yet!)

C.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Thijs van Dijk]

On 11 December 2015 at 05:51, Andy Bradford 
wrote:

> If one wants privacy on a website then more is required than just HTTPS.
>

Right. *I* just want a reasonable (256-bit) guarantee that the signify keys
on my screen are the ones the OpenBSD authors intended me to see.

I currently just assume they are correct because it'd be enormously complex
to spoof the entire OpenBSD distribution, but I souldn't have to rely on
"security through effort involved".

Remember the guy who tried to securely download PuTTY? He couldn't

.
Be snobbish all you want about using Windows and expecting any level
security, but having to give your SSH login info to an unauthenticated
binary from the internet because there is no other option is a pretty
serious problem, which could easily have been prevented by simply enabling
HTTPS.

-Thijs

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Anthony J. Bentley]

"Constantine A. Murenin" writes:
> On 8 December 2015 at 19:26, Anthony J. Bentley  wrote:
> > Giancarlo Razzolini writes:
> >> One of the main benefits of the TLS wouldn't only be to render
> >> impossible for anyone to know which pages you're accessing on the site,
> >> but also the fact that we would get a little more security getting the
> >> SSH fingerprints for the anoncvs servers. Having them in clear text as
> >> they are today, isn't very secure.
> >
> > Another attack currently possible against www.openbsd.org is changing
> > the https://openbsdstore.com links to http://openbsdstore.com, and
> > running sslstrip on that. Or the PayPal links...
> 
> For real!  And yet another attack currently possible against
> www.openbsd.org is being able to view the web-site from any OpenBSD
> release, even the early ones that did include lynx in base
> (http://mdoc.su/OpenBSD-2.3/lynx.1), yet are surely missing not only
> TLSv1.2 (if not OpenSSL in the first place!), but the requisite CA
> entries in their corresponding cert.pem file as well (that is, if such
> file was even present).

Why even bring up OpenBSD 2.3? Anyone running that 19 years after its
release has much bigger problems than not being able to connect to
www.openbsd.org.

> And if you're in Kazakhstan, it's also possible to view
> www.openbsd.org without any issues or security warnings, and will
> continue being so even after 2016-01-01 when the new telecommunication
> directive takes force.  (Or was the feature to ignore invalid
> certificates already added to lynx nowadays?)

I can't tell if you're saying it's a *good* thing that http provides no
notice that your connection is compromised. Are you serious?

Look, the whole CA model comes with a lot of baggage. Let's Encrypt has
elements of a new approach but is still tied to that way of thinking.
Talking on misc@ won't make www.openbsd.org more secure.

But you're defending telnet in 2015.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Kamil Cholewiński]

> The official CD set contains the signify keys for that release and the
> next one.  Once you have a known good copy of one set, you can always obtain
> future ones securely.
>
> You don't even need to use the CD set to install, just as a way of obtaining
> the signify keys with a high degree of confidence.

This is the real thing bothering me. I don't even have a CD drive
available, and I was about to ask if it would be possible to get the
signify keys via paper mail in exchange for a donation. But both paper
and CDs can be intercepted and tampered with (with some effort).

> I currently just assume they are correct because it'd be enormously
> complex to spoof the entire OpenBSD distribution, but I souldn't have
> to rely on "security through effort involved".

Exactly, and this is a problem with the CDs too. There's currently no
way to securely bootstrap the chain of trust. HTTPS is a way to do that.

Yes, we would have to rely on third parties (CAs). It can be optional
(so that a text browser from an ancient unsupported release can still
access plain HTTP version fine). It can be just a single page like
keys.openbsd.org so that there are few extra computing resources used.
It doesn't have to be Let's Encrypt - heck, I'm willing to go to
RapidSSL or whoever and pay for it myself if someone can give me a CSR
and assist with domain validation.

K.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Thijs van Dijk]

On 11 December 2015 at 12:28, Stefan Sperling  wrote:

> I would consider signify keys printed on CDs and copied across several
> web sites safer than trusting the hundreds of CA certs shipped with a
> standard web browser.


On 11 December 2015 at 12:35, Tati Chevron  wrote:

> The official CD set contains the signify keys for that release and the
> next one.  Once you have a known good copy of one set, you can always
> obtain
> future ones securely.


Both of you are missing my point, but it's entirely possible I didn't
articulate it properly.

I know I can trust the CD's; it's one of the main reasons I buy them with
every release.
I'm saying I shouldn't *have* to rely on snail-mailed physical media. We,
as a species, have thought of a solution to this problem long ago.

Sure that solution isn't perfect, but if I can guess at the list's
attitude, I'd say it's this:

>  "If we can't make it impossible to intercept traffic, we shouldn't
bother with making it merely fiendishly difficult."

which I think is unnecessarily fatalistic.


In either case, I'd be willing to put my money where my mouth is.
Whom do I contact about running a site mirror?

-Thijs

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Tati Chevron]

On Fri, Dec 11, 2015 at 12:48:19PM +0100, Thijs van Dijk wrote:

I'm saying I shouldn't *have* to rely on snail-mailed physical media. We,
as a species, have thought of a solution to this problem long ago.


I agree in principle that we shouldn't have to rely in physical media to
obtain the keys with a high degree of confidence.  Currently, though, it
is a good way.


Sure that solution isn't perfect, but if I can guess at the list's
attitude, I'd say it's this:


 "If we can't make it impossible to intercept traffic, we shouldn't

bother with making it merely fiendishly difficult."

which I think is unnecessarily fatalistic.


I think the attitude is more of priorities and the best way to expend
time and effort.

The OP was talking about https access to the entire www.openbsd.org site
whereas the discussion has now moved to obtaining the CVS tree and the
signify keys securely, which is a somewhat different issue.

My previous point was that once you have obtained ONE signify key,
you can obtain every future -release and verify it's integrity without
ever buying another CD.  You can't follow -current and be sure of the
integrity of what you are downloading.  Of course, if anybody did
tamper with a CVS checkout of the tree, it's quite possible that you
would notice when things didn't work as expected, or future patches
didn't apply, it would depend on the sophistication of the tampering.

My personal opinion is that https://www.openbsd.org would be rather
pointless, and lead people to a false sense of security, whereas
some kind of encryption and authentication for CVSync would be useful.

On the other hand, an increase in the general proportion of web traffic
that is encrypted does make mass surveilance more time consuming and
less practical.  Making www.openbsd.org available via https would not
contribute much at all to that, and would take resources away from
the project that could be used for other things.


In either case, I'd be willing to put my money where my mouth is.
Whom do I contact about running a site mirror?


Why would we trust your mirror?

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Tati Chevron]

On Fri, Dec 11, 2015 at 12:58:38PM +0100, Kamil Cholewi??ski wrote:

This is the real thing bothering me. I don't even have a CD drive
available, and I was about to ask if it would be possible to get the
signify keys via paper mail in exchange for a donation.


The official CDs have the signify key physically printed on them.


But both paper
and CDs can be intercepted and tampered with (with some effort).


Well then you need to meet Theo in person and obtain the keys from him
directly.  Except, how would you know it was really Theo?


I currently just assume they are correct because it'd be enormously
complex to spoof the entire OpenBSD distribution, but I souldn't have
to rely on "security through effort involved".


Exactly, and this is a problem with the CDs too. There's currently no
way to securely bootstrap the chain of trust. HTTPS is a way to do that.


Would you really trust HTTPS more than a physical CD being mailed to
you???


Yes, we would have to rely on third parties (CAs). It can be optional
(so that a text browser from an ancient unsupported release can still
access plain HTTP version fine). It can be just a single page like
keys.openbsd.org so that there are few extra computing resources used.
It doesn't have to be Let's Encrypt - heck, I'm willing to go to
RapidSSL or whoever and pay for it myself if someone can give me a CSR
and assist with domain validation.


If you want to rely on third parties, I can send you a copy of the
signify keys, signed by my PGP key.  How would that help you at all?

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Tati Chevron]

On Fri, Dec 11, 2015 at 04:37:39AM -0700, Anthony J. Bentley wrote:

Why even bring up OpenBSD 2.3? Anyone running that 19 years after its
release has much bigger problems than not being able to connect to
www.openbsd.org.


I must admit that since gopher://openbsd.org shut down, and tenex support
was removed from FTP, the overall user experience of OpenBSD has really
deteriorated...

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Thijs van Dijk]

On 11 December 2015 at 13:10, Tati Chevron  wrote:

> In either case, I'd be willing to put my money where my mouth is.
>> Whom do I contact about running a site mirror?
>>
>
> Why would we trust your mirror?


Touché.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Giancarlo Razzolini]

Em 10-12-2015 20:03, Christian Weisgerber escreveu:
> The true elephant in the room is that I can't get the current OpenBSD
> source tree securely.  (Well, _I_ can if push comes to shove, but
> the general user community can't.)  CVSync?  No integrity or
> authenticity.  AnonCVS over SSH?  Nope, no integrity or authenticity
> because the mirror itself got the tree over CVSync.  Assuming you
> trust the mirror in the first place.

I agree with you. We don't want TLS to hide the fact that we are
accessing the openbsd site. We want TLS to get a little extra confidence
that what we are seeing on our screen is what the OpenBSD devs wanted us
to see. Someone mentioned signify keys also. Nowadays if I want to be
(kind of) sure I got everything right, I need to download the files from
different mirrors, using different internet connections, using vpn's and
tor, etc.

The TLS could be implemented on a non mandatory way, you don't need to
redirect HTTP connections to HTTPS ones. But it would be nice to have
the option, at least.

Cheers,
Giancarlo Razzolini

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Thijs van Dijk]

On 11 December 2015 at 14:16, Tati Chevron  wrote:

> But even if PKI were actively on fire at the moment (which it is not),
>> what's wrong with doing both?
>>
>
> Basically the gain verses the effort and resources expended.
>
> I agree that there is a value in distributing keys and source code in a way
> that makes tampering difficult or highly visible.
>
> I disagree that serving www.openbsd.org over https is a good way of doing
> that.


Fair enough.
Though I personally still think it'd be a good idea, I am just a stranger
on the internet and this is not a vote.

-Thijs

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Constantine A. Murenin]

On 11 December 2015 at 02:58, Thijs van Dijk  wrote:
> On 11 December 2015 at 05:51, Andy Bradford 
> wrote:
>
>> If one wants privacy on a website then more is required than just HTTPS.
>>
>
> Right. *I* just want a reasonable (256-bit) guarantee that the signify keys
> on my screen are the ones the OpenBSD authors intended me to see.
>
> I currently just assume they are correct because it'd be enormously complex
> to spoof the entire OpenBSD distribution, but I souldn't have to rely on
> "security through effort involved".
>
> Remember the guy who tried to securely download PuTTY? He couldn't
> 

And I couldn't access his web-site from an OpenBSD box:

% lynx -dump 
https://noncombatant.org/2014/03/03/downloading-software-safely-is-nearly-impossible/

Looking up noncombatant.org
Making HTTPS connection to noncombatant.org
SSL callback:unable to get local issuer certificate, preverify_ok=0, ssl_okay=0
Retrying connection without TLS.
Looking up noncombatant.org
Making HTTPS connection to noncombatant.org
Alert!: Unable to make secure connection to remote host.

lynx: Can't access startfile
https://noncombatant.org/2014/03/03/downloading-software-safely-is-nearly-impossible/
%

C.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Tati Chevron]

On Fri, Dec 11, 2015 at 01:53:04PM +0100, Thijs van Dijk wrote:

On 11 December 2015 at 13:17, Tati Chevron  wrote:


Would you really trust HTTPS more than a physical CD being mailed to
you???



Yes.

Both provide some level of accountability, however with PKI you explicitly
trust a limited (though big) numer of third parties to do their job
properly, and in the case of a screwup, at least everyone involved is nice
enough to leave their name in the certificate chain. The same can't be said
for the hundreds of anonymous hands that handle my snail mail.


On the other hand, if somebody actually received a fake OpenBSD CD in
the mail, and it was discovered, it would be a huge news story within the
IT industry.  A bad download, much less so.

Some years ago, when the Linux kernel was managed with BitKeeper, somebody
tried to introduce malicious code into a CVS gateway.  It was quickly
discovered by Larry McVoy during normal integrity checks.  It was a news
story for a while then faded away.  Who remembers it now?  On the other hand,
physical interception, tampering and replacement of a disc set for a project
like OpenBSD would catch the interest of the IT industry, and conspiracy
theories would run wild.

It's usually relatively easy to hack into something.  It's much more difficult
to cover your tracks.


But even if PKI were actively on fire at the moment (which it is not),
what's wrong with doing both?


Basically the gain verses the effort and resources expended.

I agree that there is a value in distributing keys and source code in a way
that makes tampering difficult or highly visible.

I disagree that serving www.openbsd.org over https is a good way of doing
that.

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Raul Miller]

On Fri, Dec 11, 2015 at 7:10 AM, Tati Chevron  wrote:
> Why would we trust your mirror?

A couple things to keep in mind here:

(1) Security can never be perfect.
(2) Security does not have to be perfect.

(That said... sometimes traditional computer security seems like
people are trying to put bank vault doors on picket fences. And, ok,
given the state of the internet, there's some validity to that
approach. But I imagine we should be thinking about other approaches,
also.)

Anyways, for distributions, you need good ways of detecting problems.
Then, when you find one, you will at least gain some information about
your threats.

So:

(1) shasums, and other signatures. The more the merrier, within
practical limits. They can be spoofed, but plausibly spoofing several
is difficult. You should expect attackers to want to hit easier
targets.

(2) out-of-band comparisons. This does not need to be frequent, but
needs to be happening. If people adopt rituals where they sometimes
download from websites, sometimes compare web site contents with cd
contents, and also sometimes check electronic copies of signatures
with paper copies, you will catch infections sooner or later. One of
the more important characteristics, here, is probably the time delays
in the comparisons.

(3) Have some ideas of what to do when you find a problem. Rewriting
or replacing or discarding the affected systems is one approach.
Involving people who have reason to care can be another approach. This
is where having a good audience can help - industry, politicians,
volunteer organizations, etc. all have an aspect where they try to
engage lots of people. If you are supporting them (don't worry too
much about the degree of support - it mostly doesn't matter) they'll
quite probably be happy to help when you need it (especially if they
can also see how to advance their own goals - which, ok, will
sometimes be a pain).

Anyways... there's plenty more nuances than this quick writeup. The
basic approach is to drive up the costs/effort required for
sophisticated and organized attackers while also catching the flaws
which will inevitably arise (through hardware failures if nothing
else, but school-age pranks are another plausible candidate for
problems).

I hope some of this helps,

-- 
Raul

P.S. the three biggest state-level threats are probably the three most
populated countries. China and India want to destroy some parts of
their populations while maintaining loyalty of their core population
(because they can't feed them all, but you can see this in the news,
for example in reports about rotting food, perhaps tons of it - people
are strange). The USA doesn't have the food issue and (because of its
structure) places a higher priority on popularity/loyalty, but is
under immense long-term pressure to fit in  (whatever that means). I'm
not sure what to do about any of that, but I think this point of view
does help understand what was happening with the NSA but also it's why
the whole "for the people" quip gets the emotional shadings that it
gets. I can't do much about this, but maybe someone else will have
some good ideas? And, of course, there's plenty of smaller countries
which have their own personality-driven issues, wars and malware
havens.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Thijs van Dijk]

On 11 December 2015 at 13:17, Tati Chevron  wrote:

> Would you really trust HTTPS more than a physical CD being mailed to
> you???


Yes.

Both provide some level of accountability, however with PKI you explicitly
trust a limited (though big) numer of third parties to do their job
properly, and in the case of a screwup, at least everyone involved is nice
enough to leave their name in the certificate chain. The same can't be said
for the hundreds of anonymous hands that handle my snail mail.

But even if PKI were actively on fire at the moment (which it is not),
what's wrong with doing both?

-Thijs

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Tati Chevron]

On Fri, Dec 11, 2015 at 01:28:04PM +0100, Kamil Cholewi??ski wrote:

The official CDs have the signify key physically printed on them.


You press a new CD, print a new cover, etc.


...and intercept the package being delivered to you?

Yes, it's possible, but somebody who had the resources to go to that
extreme, and a motive to single you out as a target, would presumably
have other ways to invade your privacy and integrity open to them.


If you want to rely on third parties, I can send you a copy of the
signify keys, signed by my PGP key.  How would that help you at all?


Sounds reasonable to me.


In what way does this help?

] -BEGIN PGP SIGNED MESSAGE-
] Hash: SHA1
] 
] untrusted comment: openbsd 5.5 base public key

] RWRGy8gxk9N9314J0gh9U02lA7s8i6ITajJiNgxQOndvXvM5ZPX+nQ9h
] untrusted comment: openbsd 5.5 firmware public key
] RWTdVOhdk5qyNktv0iGV6OpaVfogGxTYc1bbkaUhFlExmclYvpJR/opO
] untrusted comment: openbsd 5.5 packages public key
] RWQQC1M9dhm/tja/ktitJs/QVI1kGTQr7W7jtUmdZ4uTp+4yZJ6RRHb5
] untrusted comment: openbsd 5.6 base public key
] RWR0EANmo9nqhpPbPUZDIBcRtrVcRwQxZ8UKGWY8Ui4RHi229KFL84wV
] untrusted comment: openbsd 5.6 firmware public key
] RWT4e3jpYgSeLYs62aDsUkcvHR7+so5S/Fz/++B859j61rfNVcQTRxMw
] untrusted comment: openbsd 5.6 packages public key
] RWSPEf7Vpp2j0PTDG+eLs5L700nlqBFzEcSmHuv3ypVUEOYwso+UucXb
] untrusted comment: openbsd 5.7 base public key
] RWSvUZXnw9gUb70PdeSNnpSmodCyIPJEGN1wWr+6Time1eP7KiWJ5eAM
] untrusted comment: OpenBSD 5.7 firmware public key
] RWSuRBL44FVkb2QuvtlwOJmzS9UJtbKZd7GEYcol8HPXu4On/Ct1LoZr
] untrusted comment: openbsd 5.7 packages public key
] RWTJ1iHLn/zcvJJSbxJIEU9ChlfAlU16XoLLxmxciliOFWfTLyOv0vQs
] untrusted comment: openbsd 5.8 base public key
] RWQNNZXtC/MqP3Eiu+6FBz/qrxiWQwDhd+9Yljzp62UP4KzFmmvzVk60
] untrusted comment: OpenBSD 5.8 firmware public key
] RWTpkvg4fhJCDx9yL4bUCou/vtAecPVTfcaaGESQeBruwX/qHToMvWh6
] untrusted comment: OpenBSD 5.8 packages public key
] RWRlkI2aFHvL/XGqD+lFerD/xUi/jnAXKwdFQwZDekYwDrEPSpSWgpI9
] untrusted comment: openbsd 5.9 base public key
] RWQJVNompF3pwfIqbg+5sxfpxmZMa3tTBaW4qbUhWje/H/M7glrA6oVn
] untrusted comment: OpenBSD 5.9 firmware public key
] RWSdmaNkytzh6BApmPSNSDLNg26ZaXlY8g/879UvLdo3rjbsby76Eda1
] untrusted comment: OpenBSD 5.9 packages public key
] RWSLRYDCTJeWLIScncqwGuXK6JVXDcIyRT0q+0m30MXXG4W2xWS4NZBP
] -BEGIN PGP SIGNATURE-
] Version: GnuPG v1
] 
] iQIcBAEBAgAGBQJWasZfAAoJELBdwBmbGNHy2gMP/1ESt/E8kDS3CtODAyehvheH

] 5j0cEXBTnaVLFeu7jmGDbVIiukLBbjqJ3eQiwmwnBt3uSC0P/OyrHPlEsKc8rWqs
] dPejCdZbfPpwtBMOn4P33dblDwog7qfTGU1Qu0GO9XWmEovO4iBUYb0Nuc7nipQX
] fPyHtZZGNqvBiAGMU9i2YDzwn2tYW6gxiU0nB2SnT3acuJximw6/YrVENREQD4DD
] EekXcx8wYxBU+y3JE1fj90s1n3qXQm9s3B/Mm5/X8MIXZbi6W7dWnrIcrzDLDvyg
] ZV/4UC/90NcfUn0EKG+su8r1XuXszYDspOPz7qKPbx+X/aYCbwAlEx7ajVVj60kr
] yiuFk9yhPb7cFlR3EmuABY3P8u6N7KbeWinaXBy6dOxMYJDZgztVAcqIw72qhuNF
] NNtCY727EXlbhgF+adujDvyTFy2U2/13/vllbtOl9qaN/mYlUm1iVFdIMfLd0TGe
] Ts6AIazNZdbQxsUnglzpjhJqyNaoK73SoqwwawBDvT1TpU0T6weIdrQWWaYBjngr
] fd0xaR73GffvLO5gqnFdbikw6OGizGrGQ/YIN4354WoUzpmAXtXv8cajKVwKbP3F
] SnVzgRgPqQJDCQY3gqJ+cIHBQsL3yNTiWtq/gIYeK1W+Wm7yXKn+wKbngcyifoiG
] GnfSlG7cNb0cpB+pRJTr
] =Pzev
] -END PGP SIGNATURE-

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Thijs van Dijk]

On 11 December 2015 at 13:51, Tati Chevron  wrote:

> ...and intercept the package being delivered to you?
>
> Yes, it's possible, but somebody who had the resources to go to that
> extreme, and a motive to single you out as a target, would presumably
> have other ways to invade your privacy and integrity open to them.
>

There you have it.
Security through effort involved. We don't need to make it fiendishly
difficult because we can't make it impossible.

-Thijs

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Constantine A. Murenin]

On 11 December 2015 at 05:37, Anthony J. Bentley  wrote:
> "Constantine A. Murenin" writes:
>> On 8 December 2015 at 19:26, Anthony J. Bentley  wrote:
>> > Giancarlo Razzolini writes:
>> >> One of the main benefits of the TLS wouldn't only be to render
>> >> impossible for anyone to know which pages you're accessing on the site,
>> >> but also the fact that we would get a little more security getting the
>> >> SSH fingerprints for the anoncvs servers. Having them in clear text as
>> >> they are today, isn't very secure.
>> >
>> > Another attack currently possible against www.openbsd.org is changing
>> > the https://openbsdstore.com links to http://openbsdstore.com, and
>> > running sslstrip on that. Or the PayPal links...
>>
>> For real!  And yet another attack currently possible against
>> www.openbsd.org is being able to view the web-site from any OpenBSD
>> release, even the early ones that did include lynx in base
>> (http://mdoc.su/OpenBSD-2.3/lynx.1), yet are surely missing not only
>> TLSv1.2 (if not OpenSSL in the first place!), but the requisite CA
>> entries in their corresponding cert.pem file as well (that is, if such
>> file was even present).
>
> Why even bring up OpenBSD 2.3? Anyone running that 19 years after its
> release has much bigger problems than not being able to connect to
> www.openbsd.org.

Not really.  It just works.  And there's always time to upgrade to a
newer OpenBSD release, since those continue to be served through http
without any issues.

>
>> And if you're in Kazakhstan, it's also possible to view
>> www.openbsd.org without any issues or security warnings, and will
>> continue being so even after 2016-01-01 when the new telecommunication
>> directive takes force.  (Or was the feature to ignore invalid
>> certificates already added to lynx nowadays?)
>
> I can't tell if you're saying it's a *good* thing that http provides no
> notice that your connection is compromised. Are you serious?

But http connections aren't compromised.  They're just monitored
passively.  (And it's all public data, and, as mentioned, even with
https, the hostnames would still have leaked.)

Since it's impossible to do the same with https, they have to be MitM'ed.

>
> Look, the whole CA model comes with a lot of baggage. Let's Encrypt has
> elements of a new approach but is still tied to that way of thinking.
> Talking on misc@ won't make www.openbsd.org more secure.
>
> But you're defending telnet in 2015.

No.  If you look closely at what Theo has said, especially around
pledge(2), telnet has more problems that just lack of encryption.
Kinda like HTTPS has few-too-many downfalls and bad policies other
than the availability of encryption.

C.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[nanaya]

Hi,

On Fri, Dec 11, 2015, at 23:39, Raul Miller wrote:
> On Fri, Dec 11, 2015 at 7:10 AM, Tati Chevron 
> wrote:
> > Why would we trust your mirror?
> 
> A couple things to keep in mind here:
> 
> (1) Security can never be perfect.
> (2) Security does not have to be perfect.
> 


And here's a kind reminder that default openbsd base install already
included a bunch of root certificates[1] which hopefully means those
listed in this file are deemed trustworthy to a certain level.

[1]
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/cert.pem?rev=1.7

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Giancarlo Razzolini]

Em 11-12-2015 09:28, Stefan Sperling escreveu:
> I would consider signify keys printed on CDs and copied across several
> web sites safer than trusting the hundreds of CA certs shipped with a
> standard web browser.

Didn't we just established that with HPKP you can disregard the CA
completely? At least if you trust your fist access to the site. But I
think this thread followed its course, lets move on.

Cheers,
Giancarlo Razzolini

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Anthony J. Bentley]

Kevin Chadwick writes:
> What is your problem with it, there are many VPN services promoted
> precisely for this issue as it completely rather than partially stops
> ISP's monitoring traffic like TalkTalks homesafe service that is
> likely hackable itself.

Why encrypt anything? Just run it through a VPN! Who needs SSH when you
can run telnet over a VPN? It completely protects the connection! Well,
except for the endpoint from the VPN to the destination server. And the
VPN provider itself can listen to or spoof whatever he wants. But hey,
who cares about that?

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Stuart Henderson]

On 2015-12-11, Constantine A. Murenin  wrote:
> On 11 December 2015 at 02:58, Thijs van Dijk  wrote:
>> On 11 December 2015 at 05:51, Andy Bradford 
>> wrote:
>>
>>> If one wants privacy on a website then more is required than just HTTPS.
>>>
>>
>> Right. *I* just want a reasonable (256-bit) guarantee that the signify keys
>> on my screen are the ones the OpenBSD authors intended me to see.
>>
>> I currently just assume they are correct because it'd be enormously complex
>> to spoof the entire OpenBSD distribution, but I souldn't have to rely on
>> "security through effort involved".
>>
>> Remember the guy who tried to securely download PuTTY? He couldn't
>> 
>
> And I couldn't access his web-site from an OpenBSD box:
>
> % lynx -dump 
> https://noncombatant.org/2014/03/03/downloading-software-safely-is-nearly-impossible/
>
> Looking up noncombatant.org
> Making HTTPS connection to noncombatant.org
> SSL callback:unable to get local issuer certificate, preverify_ok=0, 
> ssl_okay=0
> Retrying connection without TLS.
> Looking up noncombatant.org
> Making HTTPS connection to noncombatant.org
> Alert!: Unable to make secure connection to remote host.
>
> lynx: Can't access startfile
> https://noncombatant.org/2014/03/03/downloading-software-safely-is-nearly-impossible/
> %
>
> C.
>
>

Works in -current - update /etc/ssl/cert.pem.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Oriol Demaria]

I agree, but no one mentioned DANE, I think that's the future and the
way to go. With DANE in theory you wouldn't need a CA. I think it's an
excellent way to establish authenticity of your content. Problem is that
no browser supports it by default, and DNSsec use is marginal.

Regards,

Giancarlo Razzolini writes:

> Em 10-12-2015 20:03, Christian Weisgerber escreveu:
>> The true elephant in the room is that I can't get the current OpenBSD
>> source tree securely.  (Well, _I_ can if push comes to shove, but
>> the general user community can't.)  CVSync?  No integrity or
>> authenticity.  AnonCVS over SSH?  Nope, no integrity or authenticity
>> because the mirror itself got the tree over CVSync.  Assuming you
>> trust the mirror in the first place.
>
> I agree with you. We don't want TLS to hide the fact that we are
> accessing the openbsd site. We want TLS to get a little extra confidence
> that what we are seeing on our screen is what the OpenBSD devs wanted us
> to see. Someone mentioned signify keys also. Nowadays if I want to be
> (kind of) sure I got everything right, I need to download the files from
> different mirrors, using different internet connections, using vpn's and
> tor, etc.
>
> The TLS could be implemented on a non mandatory way, you don't need to
> redirect HTTP connections to HTTPS ones. But it would be nice to have
> the option, at least.
>
> Cheers,
> Giancarlo Razzolini

-- 
Oriol Demaria
0x58415679

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Kamil Cholewiński]

> The official CDs have the signify key physically printed on them.

You press a new CD, print a new cover, etc.

> If you want to rely on third parties, I can send you a copy of the
> signify keys, signed by my PGP key.  How would that help you at all?

Sounds reasonable to me.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Kevin Chadwick]

> Kevin Chadwick writes:
> > The cvs page fingerprint page could be https enabled, however you can
> > use googles cache over https, also buy a CD to help the project greatly
> > would do far more for world security than TLS everywhere and even look
> > at mailing list archives over https as a web of trust.
> > 
> > ISPs snooping is a compelling reason but not enough for me to adopt
> > HSTS, a VPN makes more sense. I changed my ISP instead though ;).  
> 
> There are valid complaints about HTTPS (generally involving the CA
> system, sthen brought some of them up), but some of these responses are
> just ridiculous. I mean, really? "ISPs snooping is a compelling reason
> but not enough for me to adopt SSH instead of telnet, a VPN makes more
> sense."
> 

If you are going to quote and criticise a comment then you should

a.) Get the quote right
b.) backup your criticisms

What is your problem with it, there are many VPN services promoted
precisely for this issue as it completely rather than partially stops
ISP's monitoring traffic like TalkTalks homesafe service that is
likely hackable itself.

HSTS is not telnet?? it is something that I looked into in the early
days of it's support and decided that unfortunately I could not
deploy it on my site as I believe it still means all of a domain must
use https once a browser has been notified for x time period as tracking
individual pages would be a huge burden for browsers.

> And you would trust signify keys from Google Cache? Come on.

Do I trust google... with this yes, as much as OpenBSD especially
considering they were acquired over http, of course not and I never
said I did. My meaning (if you had actually read my previous thread
mails) was that a couple of pages over https would be an improvement
but all of OpenBSD.org would be sub optimum. I'm not trying to avoid
the NSA. The point is that it's not the biggest issue in the world as
you can confirm in various ways like getting them over https as a
*second* check and it is hardly likely that a hacker can modify both
(same network as openbsd.org) and not get noticed. I'm guessing the NSA
avoid getting any snooping noticed btw, unless it's on purpose!

-- 

KISSIS - Keep It Simple So It's Securable

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Christian Weisgerber]

On 2015-12-08, szs  wrote:

> So with letsencrypt here, how about making the main site
> default to https? Is this a good idea or is this a great idea?

I would like it a lot if www.openbsd.org and cvsweb.openbsd.org
switched to https, but I'm not in a position to make it happen.

Much of the discussion seems silly: We don't do it because it doesn't
provide perfect security? That's exactly the opposite approach to
Theo's idea about security in OpenBSD. And encrypting everything
makes mass surveillance harder.

The true elephant in the room is that I can't get the current OpenBSD
source tree securely.  (Well, _I_ can if push comes to shove, but
the general user community can't.)  CVSync?  No integrity or
authenticity.  AnonCVS over SSH?  Nope, no integrity or authenticity
because the mirror itself got the tree over CVSync.  Assuming you
trust the mirror in the first place.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Andy Bradford]

Thus said Jason Barbier on Tue, 08 Dec 2015 10:14:37 -0800:

> It is a  read only site, the  privacy you seek is breached  as soon as
> you make a DNS call to openbsd.org

Not  to mention  the Subject  on the  SSL certificate  will most  likely
be  www.openbsd.org, and  perhaps  there's  also SNI,  all  of which  is
transmitted in the plain.

If one wants privacy on a website then more is required than just HTTPS.

Andy
-- 
TAI64 timestamp: 4000566a5669

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Craig Skinner]

On 2015-12-08 Tue 12:06 PM |, szs wrote:
> So with letsencrypt here, how about making the main site
> default to https? Is this a good idea or is this a great idea?
> 

Copy & Paste from 2013: "OpenBSD site SSL"
http://marc.info/?t=13815459562=1=2

Please don't.

That would slow it down & eliminate cachability - increasing network
load & costs.

Encryption soaks up CPU time & electricty costs,
leaving less money for hackathons, etc, etc...

There's no personal data & no point.

Anyway, THIS email is being sent in clear text from Scotland to Canada.
It will also be archived and published on several public websites.

-- 
Miksch's Law:
If a string has one end, then it has another end.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Anthony J. Bentley]

Kevin Chadwick writes:
> The cvs page fingerprint page could be https enabled, however you can
> use googles cache over https, also buy a CD to help the project greatly
> would do far more for world security than TLS everywhere and even look
> at mailing list archives over https as a web of trust.
> 
> ISPs snooping is a compelling reason but not enough for me to adopt
> HSTS, a VPN makes more sense. I changed my ISP instead though ;).

There are valid complaints about HTTPS (generally involving the CA
system, sthen brought some of them up), but some of these responses are
just ridiculous. I mean, really? "ISPs snooping is a compelling reason
but not enough for me to adopt SSH instead of telnet, a VPN makes more
sense."

And you would trust signify keys from Google Cache? Come on.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Giancarlo Razzolini]

Em 08-12-2015 23:23, Stuart Henderson escreveu:
> I wasn't aware that
> it lets you disregard the CAs though

Once the client has the two certs pinned (the primary and the backup),
if a malicious CA try to impersonate the server using a forged (although
perfectly valid) certificate, the client shouldn't connect to it,
because it already has the fingerprint pinned. It is the same rationale
as ssh host keys, trust on first use.

But, by the way this thread evolved, we're beating a dead horse here now.

Cheers,
Giancarlo Razzolini

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Kevin Chadwick]

> In the case of www.openbsd.org, using HTTPS isn't so much about
> privacy as it is about integrity. Yes, signify(1) is a thing, but
> using HTTPS in addition to it would make release and package
> downloads more difficult to tamper with.

Well packages usually come from mirrors which I know from before
signify most don't offer https.

All you would achieve now is to make it more likely that people
couldn't patch security holes in their systems due to mirrors going
down.

> Another attack currently possible against www.openbsd.org is changing
> the https://openbsdstore.com links to http://openbsdstore.com, and
> running sslstrip on that. Or the PayPal links...

So use HSTS, nope because now users don't bother checking as they
have a false sense of security and when they find a site that doesn't
use HSTS they miss the downgrade. Also users still need to check the
domain is correct so checking if the bar is bright green like with the
xombrero browser that does things properly mutes any point.

> (For the record, I highly approve of many https efforts, but think
> that https everywhere would be an utter disaster.)

Here hear

The cvs page fingerprint page could be https enabled, however you can
use googles cache over https, also buy a CD to help the project greatly
would do far more for world security than TLS everywhere and even look
at mailing list archives over https as a web of trust.

ISPs snooping is a compelling reason but not enough for me to adopt
HSTS, a VPN makes more sense. I changed my ISP instead though ;).

-- 

KISSIS - Keep It Simple So It's Securable

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Michael McConville]

Jason Barbier wrote:
> szs wrote:
> > Not for security.
> > For privacy.
> 
> It is a read only site, the privacy you seek is breached as soon as
> you make a DNS call to openbsd.org

There are still some privacy benefits to using HTTPS. It will confound a
lot of simple filtering and monitoring software, and what you're reading
on the site is pretty obfuscated. It also helps security on sketchy
networks.

HTTPS isn't a perfect solution, but it's something. Especially when ISPs
are starting to inject beacons into HTTP requests and more closely
observe usage.

That said, I suspect none of the sysadmins have the time or interest,
and that's understandable.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Jason Barbier]

It is a read only site, the privacy you seek is breached as soon as you
make a DNS call to openbsd.org

-- 
Jason Barbier | E: jab...@serversave.us
GPG Key-ID: B5F75B47(http://kusuriya.devio.us/pubkey.asc)

On Tue, Dec 8, 2015, at 09:58 AM, szs wrote:
> Not for security.
> For privacy.
> 
> 
>  Original Message 
> Subject: Re: letsencrypt && https && openbsd.org =
> https://www.openbsd.org/
> Local Time: December 8 2015 5:36 pm
> UTC Time: December 8 2015 5:36 pm
> From: s...@spacehopper.org
> To: misc@openbsd.org
> 
> On 2015-12-08, szs <s...@protonmail.com> wrote:
> > So with letsencrypt here, how about making the main site
> > default to https? Is this a good idea or is this a great idea?
> 
> Don't mistake encryption for security.
> 
> Besides, who is going to agree to the Subscriber Agreement and indemnify
> ISRG?

letsencrypt && https && openbsd.org = https://www.openbsd.org/

[szs]

So with letsencrypt here, how about making the main site
default to https? Is this a good idea or is this a great idea?

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Stefan Sperling]

On Tue, Dec 08, 2015 at 12:06:52PM -0500, szs wrote:
> Fb jvgu yrgfrapelcg urer, ubj nobhg znxvat gur znva fvgr
> qrsnhyg gb uggcf? Vf guvf n tbbq vqrn be vf guvf n terng vqrn?

I'm sorry, I couldn't read your message because it was encrypted.
How about you sign your messages instead? That way, everyone can
read it and also verify its authenticity.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[szs]

Not for security.
For privacy.


 Original Message 
Subject: Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/
Local Time: December 8 2015 5:36 pm
UTC Time: December 8 2015 5:36 pm
From: s...@spacehopper.org
To: misc@openbsd.org

On 2015-12-08, szs <s...@protonmail.com> wrote:
> So with letsencrypt here, how about making the main site
> default to https? Is this a good idea or is this a great idea?

Don't mistake encryption for security.

Besides, who is going to agree to the Subscriber Agreement and indemnify ISRG?

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Ted Unangst]

Stuart Henderson wrote:
> 
> Besides, who is going to agree to the Subscriber Agreement and indemnify ISRG?

Huh? You don't trust robots to perform surgery correctly?

oh, wrong ISRG.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Stuart Henderson]

On 2015-12-08, szs  wrote:
> So with letsencrypt here, how about making the main site
> default to https? Is this a good idea or is this a great idea?

Don't mistake encryption for security.

Besides, who is going to agree to the Subscriber Agreement and indemnify ISRG?

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Raul Miller]

On Tue, Dec 8, 2015 at 3:23 PM, Ted Unangst  wrote:
> Michael McConville wrote:
>> Yes, but it is certainly "Websense" difficult, "Verizon traffic
>> monetization dept." difficult, "nosy VPN/exit node operator" difficult,
>> and "guy in cafe with Wireshark" difficult.
>
> But we don't care about any of those people anymore. The NSA is the only bad
> guy worth caring about

Wait, what... no other governments even exist?

Or just that they are not quite so incompetent at hiding their spys?

-- 
Raul

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Ted Unangst]

Michael McConville wrote:
> Yes, but it is certainly "Websense" difficult, "Verizon traffic
> monetization dept." difficult, "nosy VPN/exit node operator" difficult,
> and "guy in cafe with Wireshark" difficult.

But we don't care about any of those people anymore. The NSA is the only bad
guy worth caring about

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Michael McConville]

Ted Unangst wrote:
> Michael McConville wrote:
> > Jason Barbier wrote:
> > > szs wrote:
> > > > Not for security.
> > > > For privacy.
> > > 
> > > It is a read only site, the privacy you seek is breached as soon as
> > > you make a DNS call to openbsd.org
> > 
> > There are still some privacy benefits to using HTTPS. It will confound a
> > lot of simple filtering and monitoring software, and what you're reading
> > on the site is pretty obfuscated. It also helps security on sketchy
> > networks.
> 
> Note that simple length correlation is enough to determine what you're
> reading. And this isn't even "NSA intern" difficult, it's "NSA internship
> interview question" difficult.

Yes, but it is certainly "Websense" difficult, "Verizon traffic
monetization dept." difficult, "nosy VPN/exit node operator" difficult,
and "guy in cafe with Wireshark" difficult.

I'll stop responding publicly, though.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Ted Unangst]

Michael McConville wrote:
> Jason Barbier wrote:
> > szs wrote:
> > > Not for security.
> > > For privacy.
> > 
> > It is a read only site, the privacy you seek is breached as soon as
> > you make a DNS call to openbsd.org
> 
> There are still some privacy benefits to using HTTPS. It will confound a
> lot of simple filtering and monitoring software, and what you're reading
> on the site is pretty obfuscated. It also helps security on sketchy
> networks.

Note that simple length correlation is enough to determine what you're
reading. And this isn't even "NSA intern" difficult, it's "NSA internship
interview question" difficult.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Giancarlo Razzolini]

Em 08-12-2015 16:24, Michael McConville escreveu:
> There are still some privacy benefits to using HTTPS. It will confound a
> lot of simple filtering and monitoring software, and what you're reading
> on the site is pretty obfuscated. It also helps security on sketchy
> networks.
>
> HTTPS isn't a perfect solution, but it's something. Especially when ISPs
> are starting to inject beacons into HTTP requests and more closely
> observe usage.
>
> That said, I suspect none of the sysadmins have the time or interest,
> and that's understandable.
I started a thread regarding TLS on the OpenBSD site some time ago, I
think it was 2013. There was startcom at the time and I even offered to
buy certs if the startcom certs weren't acceptable. I don't see why this
changed with letsencrypt in town. There wasn't interest at the time, and
I don't see why there will be now.

One of the main benefits of the TLS wouldn't only be to render
impossible for anyone to know which pages you're accessing on the site,
but also the fact that we would get a little more security getting the
SSH fingerprints for the anoncvs servers. Having them in clear text as
they are today, isn't very secure.

Also, now that we have two free TLS certs providers, one can use HPKP
and completely disregard the CA's, which is a security benefit.

Cheers,
Giancarlo Razzolini

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Anthony J. Bentley]

Giancarlo Razzolini writes:
> One of the main benefits of the TLS wouldn't only be to render
> impossible for anyone to know which pages you're accessing on the site,
> but also the fact that we would get a little more security getting the
> SSH fingerprints for the anoncvs servers. Having them in clear text as
> they are today, isn't very secure.

Another attack currently possible against www.openbsd.org is changing
the https://openbsdstore.com links to http://openbsdstore.com, and
running sslstrip on that. Or the PayPal links...

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Stuart Henderson]

On 2015-12-09, Giancarlo Razzolini  wrote:
> Also, now that we have two free TLS certs providers, one can use HPKP
> and completely disregard the CA's, which is a security benefit.

Also wosign (and, sort-of, cloudflare). btw, HPKP doesn't work too well
with letsencrypt as-is (which wants to generate a new key each time).
It can be hacked around but is a bit of a pain.. (I wasn't aware that
it lets you disregard the CAs though?)

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Stuart Henderson]

On 2015-12-08, Michael McConville  wrote:
> Jason Barbier wrote:
>> szs wrote:
>> > Not for security.
>> > For privacy.
>> 
>> It is a read only site, the privacy you seek is breached as soon as
>> you make a DNS call to openbsd.org
>
> There are still some privacy benefits to using HTTPS. It will confound a
> lot of simple filtering and monitoring software

For current TLS versions it is absolutely trivial to identify which
site you're connecting to, it's in cleartext in the clienthello,
there's no need to even spoof the TLS connection for this.
(Easy to log in squid. Anyone want to send a patch for dsniff? ;-)

(Doing something about this for TLS 1.3 gets discussed from time to
time on the IETF TLS mailing list, the latest iteration being
https://www.ietf.org/mail-archive/web/tls/current/msg18633.html)

> and what you're reading on the site is pretty obfuscated.

Not as much as it would be if you checked out the www tree from CVS :-)

> It also helps security on sketchy networks.
>
> HTTPS isn't a perfect solution, but it's something. Especially when ISPs
> are starting to inject beacons into HTTP requests and more closely
> observe usage.
>
> That said, I suspect none of the sysadmins have the time or interest,
> and that's understandable.

I don't think this is a "time or interest" thing. I haven't seen any
proposed viable solutions for the problems that have been mentioned when
this has come up on the lists in the past.

The technically-cleanest way I can think of would be to publish a
name-constrained private root and sign from there, but the only place we
could sanely distribute that root is cert.pem which doesn't work nicely
for !OpenBSD or for gui browsers on OpenBSD, and while that would have
some uses, the list questions will then change to "why don't you use a
publically recognized root", so I don't really consider that viable
either.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Raul Miller]

On Tue, Dec 8, 2015 at 11:22 PM, Nick Holland
 wrote:
> https is a joke.  IF and WHEN it works properly, it's too complex for
> the real world to understand (ahem...and even recognize).

That's not the joke, though - that's the punchline.

(1) "Secure" and "Security" mean different (and often conflicting)
things to different people.

(2) Web browsers are broken by (details elided).

Traditional solutions to these issues seem to involve yelling at
people and/or escalating violence and/or ignoring the problems.

But that's ok. It's not like any of us had anything better to do with
our time, right?

(For the record, I highly approve of many https efforts, but think
that https everywhere would be an utter disaster.)

-- 
Raul

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Delan Azabani]

On Wed, Dec 9, 2015 at 12:22 PM, Nick Holland
 wrote:
> HAHAHHAHAHA...
> you think adding a certificate changes this?
> https is a joke.

"Some people implement HTTPS poorly sometimes, so we shouldn't try."

The amount of effort "wasted" on Let's Encrypting the OpenBSD website
is so small compared to the immediate benefits that we would gain by
doing so. Nothing is perfect, and no approach is enough to be called
"security" on its own. Defense in depth calls for doing what we can
to provide multiple layers of security.

In the case of www.openbsd.org, using HTTPS isn't so much about
privacy as it is about integrity. Yes, signify(1) is a thing, but
using HTTPS in addition to it would make release and package
downloads more difficult to tamper with.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Nick Holland]

On 12/08/15 20:26, Anthony J. Bentley wrote:
> Giancarlo Razzolini writes:
>> One of the main benefits of the TLS wouldn't only be to render
>> impossible for anyone to know which pages you're accessing on the site,
>> but also the fact that we would get a little more security getting the
>> SSH fingerprints for the anoncvs servers. Having them in clear text as
>> they are today, isn't very secure.
> 
> Another attack currently possible against www.openbsd.org is changing
> the https://openbsdstore.com links to http://openbsdstore.com, and
> running sslstrip on that. Or the PayPal links...

HAHAHHAHAHA...
you think adding a certificate changes this?

Pull up a chair, lemme tell you a story.


I used to work for a company I'm sure you have heard of -- Two letters,
starts with a G.  And they don't make cars.  When I hired in, one of my
coworkers told me, "Congrats, you now work for four or five of the
largest companies in the world".  That company.

This company was a target for cyber attack for a whole lot of reasons,
and they did all kinds of (token) security education things -- including
an annual "Security Week" ("token" as in chanting rules that are not
understood and easily broken), and lots of time and effort was put into
compliance, security technology, buzzwords and check-boxes so that
effort could be demonstrated.  And of course, there were lessons on
https and encryption and how encryption solves everything and always
look for the https:// and and and ...

My team was a hot-shot security team...I worked with some absolutely
amazing people in the world of incident response, including one who
literally wrote the book on it.  We tended to live in our own little
world significantly detached from the rest of the company.  We had our
own infrastructure in fact, which was part of my job to run.  So, most
of us didn't actually USE a lot of the corporate infrastructure, such as
the company web portal much.  But after I was there about three years,
they refreshed my laptop, and because things were kinda quiet in my job
at that point, I got to spend a little time looking around the new
machine, which I didn't do when I first started.  And this time, I
didn't immediately change the browser start screen from the company
portal to something more useful.

And ... I looked at the company portal for the first time...closely.
It looked something like this:

+-+
| url: http://intranet.bla.com/stupid/long/url/portal/|
+-+
| |
| +--+|
| |   _ Please log in!   ||
| | ,(_),||
| | |   |   SSO:__   ||
| | |___|PW:__   ||
| |  ||
| |  ||
| +--+|
| |
| |
+-+

That little thing that looks like an "i" is supposed to be a lock
graphic.  My ASCII art skills are lame.  But then, the "Single Sign-On"
screen on the portal wasn't much more than my ASCIIart, either.  A box.
 A couple boxes for user ID (SSO) and PW.  And a graphic of a lock.

And I stare at this some more...and realize that my eyes aren't fooling
me.  That's a graphic of a lock.  And no https:// in the URL.  No
encryption in sight.  I can't believe where I'm sitting and what I'm
looking at.

I walk over to one of my coworkers, a smart guy who knows the importance
and tools of "compliance", but understand real security, too.  I have
him go to the portal, and he immediately, reflexively starts typing in
his SSO and PW, in spite of my yelling "STOP! STOP!  DON'T DO IT!".  He
looked at me puzzled.  I tap the URL on his screen.  I tap the lock
graphic.  His look goes from "What silly crap has Nick got for me this
time?" to pure panic.
"oh. my. God.  We are going to have to do a password roll" (a change of
pw for EVERY SINGLE PERSON in the company -- as he realized this was a
major breach of security protocols).

(On further investigation, it turned out the BOX was a frame that did
happen to be encrypted, so there was no actual need for a PW roll, and
there was no actual obvious security event...but again, there was
absolutely nothing "proving" the communications was encrypted, and
anyone could set up a rogue page and snag passwords).

I put a ticket in to have this fixed.  It was closed without action,
with the explanation, "well, that will be a lot of work to change, we
won't be scheduling any time on this page for a year or so".

Note that something like 100,000 users all over 

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Kevin Chadwick]

> >It would actually reduce the security and potential for DDOS against
> >openbsd.org despite the heroic efforts that have gone into LibreSSL. So
> >where's the benefit to risk analysis for OpenBSD?  
> 
> Don't you mean reduce the securiry and _increase_ the potential for
> DDOS against openbsd.org?

yeah, was gonna correct it but thought everyone would get it ;)

-- 

KISSIS - Keep It Simple So It's Securable

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Kevin Chadwick]

> > So with letsencrypt here, how about making the main site
> > default to https? Is this a good idea or is this a great idea?  
> 
> Don't mistake encryption for security.

It would actually reduce the security and potential for DDOS against
openbsd.org despite the heroic efforts that have gone into LibreSSL. So
where's the benefit to risk analysis for OpenBSD?

-- 

KISSIS - Keep It Simple So It's Securable

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Tati Chevron]

On Tue, Dec 08, 2015 at 10:11:34PM +, Kevin Chadwick wrote:

It would actually reduce the security and potential for DDOS against
openbsd.org despite the heroic efforts that have gone into LibreSSL. So
where's the benefit to risk analysis for OpenBSD?


Don't you mean reduce the securiry and _increase_ the potential for
DDOS against openbsd.org?

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com