Debian Bug report logs - #744027
Please remove StartCom Certification Authority root certificate

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Klemens Baum <klemensbaum@gmail.com>

To: submit@bugs.debian.org

Subject: Please remove StartCom Certification Authority root certificate

Date: Wed, 9 Apr 2014 15:07:08 +0200

Package: ca-certificates

Following the OpenSSL CVE-2014-0160 "Heartbleed" vulnerability [1,2],
any certificate that was used with an vulnerable version of OpenSSL (I
read somewhere 1/3 of the web) should be handled as it is compromised.

Compromised certificates have to be replaced with new ones (new keys)
and the old ones should be revoked.

StartCom provides cheap and even free SSL certificates via the
StartSSL brand. However, certificates revoking cerificates requires a
US$ 24.90 fee [3]. This discourages responsible sysadmin procedure and
and will ensure many compromised certificates remain in use. As a
consequence you can't trust certificates signed by StartCom before
2014-04-07.

Solution 1: StartCom should revoke affected certs. (unlikely[4-6])

Solution 2: StartCom should be removed from the truststore.

See also: https://bugzilla.mozilla.org/show_bug.cgi?id=994033

[1] https://www.openssl.org/news/secadv_20140407.txt
[2] http://heartbleed.com/
[3] http://www.startssl.com/?app=25#72
[4] https://news.ycombinator.com/item?id=7557764
[5] https://twitter.com/startssl/status/453583493386485760
[6] https://twitter.com/startssl/status/453631038883758080
Solution 2: StartCom should be removed from the truststore.

Message #10 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Michael Shuler <michael@pbandjelly.org>

To: 744027@bugs.debian.org

Cc: Klemens Baum <klemensbaum@gmail.com>

Subject: Re: Bug#744027: Please remove StartCom Certification Authority root certificate

Date: Wed, 09 Apr 2014 08:39:25 -0500

Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=994033

On 04/09/2014 08:07 AM, Klemens Baum wrote:
> Following the OpenSSL CVE-2014-0160 "Heartbleed" vulnerability [1,2],
> any certificate that was used with an vulnerable version of OpenSSL (I
> read somewhere 1/3 of the web) should be handled as it is compromised.
>
> Compromised certificates have to be replaced with new ones (new keys)
> and the old ones should be revoked.
>
> StartCom provides cheap and even free SSL certificates via the
> StartSSL brand. However, certificates revoking cerificates requires a
> US$ 24.90 fee [3]. This discourages responsible sysadmin procedure and
> and will ensure many compromised certificates remain in use. As a
> consequence you can't trust certificates signed by StartCom before
> 2014-04-07.
>
> Solution 1: StartCom should revoke affected certs. (unlikely[4-6])
>
> Solution 2: StartCom should be removed from the truststore.

If mozilla believes this is justification for removal, which I doubt 
will happen, then the same will happen in ca-certificates. Debian 
ca-certificates users may remove trust locally at any time, if they desire.

> See also: https://bugzilla.mozilla.org/show_bug.cgi?id=994033

Marking this as the upstream bug report.

> [1] https://www.openssl.org/news/secadv_20140407.txt
> [2] http://heartbleed.com/
> [3] http://www.startssl.com/?app=25#72
> [4] https://news.ycombinator.com/item?id=7557764

A user comment here says the CVE was cited, and StartSSL waived the 
revocation fee.

> [5] https://twitter.com/startssl/status/453583493386485760
> [6] https://twitter.com/startssl/status/453631038883758080

-- 
Kind regards,
Michael

Message #17 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Thijs Kinkhorst <thijs@debian.org>

To: Klemens Baum <klemensbaum@gmail.com>

Cc: 744027@bugs.debian.org

Subject: Re: Bug#744027: Please remove StartCom Certification Authority root certificate

Date: Wed, 9 Apr 2014 15:48:56 +0200

[Message part 1 (text/plain, inline)]

Op woensdag 9 april 2014 15:07:08 schreef Klemens Baum:
> Package: ca-certificates
> 
> Following the OpenSSL CVE-2014-0160 "Heartbleed" vulnerability [1,2],
> any certificate that was used with an vulnerable version of OpenSSL (I
> read somewhere 1/3 of the web) should be handled as it is compromised.
> 
> Compromised certificates have to be replaced with new ones (new keys)
> and the old ones should be revoked.
> 
> StartCom provides cheap and even free SSL certificates via the
> StartSSL brand. However, certificates revoking cerificates requires a
> US$ 24.90 fee [3].

Whatever you and I think of this pricing structure, people free to chose any 
provider of certificates that matches their pricing interest and that people 
are knowingly or should be knowlingly buying a product that has a certain 
price structure when they get the certificates in the first place.

Revoking a certificate is generally primarily in the interest of the owner of 
said certificate so there is incentive to actually pay this fee.

I do not believe it is Debian's place to pass judgement on which pricing 
scheme people should prefer, even if you and I personally rather pay up front 
and have no costs on revocation.


Cheers,
Thijs

[signature.asc (application/pgp-signature, inline)]

Message #22 received at 744027@bugs.debian.org (full text, mbox, reply):

From: David Wilson <dw@botanicus.net>

To: 744027@bugs.debian.org

Date: Wed, 9 Apr 2014 19:22:43 +0100

It's worth bearing in mind that a leaked private key has so far not
been reproducible on Debian, only for first request on specific
configurations of FreeBSD.

Following from that, it is really questionable whether such mass
certificate compromises have really happened, and whether removal of
Startcom CA would have any quantifiable benefit. I believe the onus is
on the bug submitter to demonstrate such a compromise has occurred
before this request should be seriously considered.

Message #27 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Jan Niehusmann <jan@gondor.com>

To: 744027@bugs.debian.org

Subject: Re: Bug#744027: Please remove StartCom Certification Authority root certificate

Date: Wed, 9 Apr 2014 20:47:50 +0200

On Wed, Apr 09, 2014 at 03:48:56PM +0200, Thijs Kinkhorst wrote:
> Whatever you and I think of this pricing structure, people free to chose any 
> provider of certificates that matches their pricing interest and that people 
> are knowingly or should be knowlingly buying a product that has a certain 
> price structure when they get the certificates in the first place.

Well, the fee was not prominently advertised. And as revocations were
free a few years ago[1], even reading all the terms and conditions back
then wouldn't have helped.

Or is one expected actively search for new fees in the FAQ when
refreshing a certificate?

(Please note that I'm not arguing that the CA should be removed - just
that the argument that people knowingly chose that pricing structure may
be invalid.)

Regards,
Jan


[1] https://cv.exbit.io/emails/startssl_heartbeat.txt

Message #32 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Raphael Geissert <geissert@debian.org>

To: 744027@bugs.debian.org

Cc: Klemens Baum <klemensbaum@gmail.com>

Subject: Re: Bug#744027: Please remove StartCom Certification Authority root certificate

Date: Wed, 9 Apr 2014 21:54:18 +0200

Control: tag -1 wontfix

On Wednesday 09 April 2014 15:39:25 Michael Shuler wrote:
[...]
> If mozilla believes this is justification for removal, which I doubt
> will happen, then the same will happen in ca-certificates. Debian
> ca-certificates users may remove trust locally at any time, if they
> desire.

Agreed, so marking it as wontfix. If anything changes upstream, it will be 
reflected here.

For those reading at home don't waste your time, nor ours, sending arguments 
or "+1"s. If anywhere, do it on mozilla's bugzilla - all the while 
respecting their policies.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net

Message #39 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Geoffrey Thomas <geofft@ldpreload.com>

To: Klemens Baum <klemensbaum@gmail.com>

Cc: 744027@bugs.debian.org

Subject: Re: Please remove StartCom Certification Authority root certificate

Date: Wed, 9 Apr 2014 12:55:31 -0700 (PDT)

On Wed, 9 Apr 2014, Klemens Baum wrote:

> StartCom provides cheap and even free SSL certificates via the
> StartSSL brand. However, certificates revoking cerificates requires a
> US$ 24.90 fee [3]. This discourages responsible sysadmin procedure and
> and will ensure many compromised certificates remain in use.

I don't believe that any browser or HTTPS client in Debian checks 
revocations with hard failures if the CRL or OCSP responder is 
unreachable, so I don't see how this is relevant for decisions regarding 
Debian's default trust store. The certificate will (it seems) get reissued 
for free with a new key, so the compromised certificate will not be in 
use. And an attacker in a position to MITM is also in a position to 
make the revocation useless:

https://news.ycombinator.com/item?id=7556909
https://www.imperialviolet.org/2012/02/05/crlsets.html
https://twitter.com/agl__/status/453602748601495553

Multiple commentors on the HN thread you link to imply that StartCom is 
happy to reissue certs for free, but they charge for revocations, for 
instance: "The title is misleading. StartCom is asking for its fee for 
revoking, that's all. Not making revocation free of cost isn't refusal to 
reissue cert."

If they were charging for reissues, there might be an argument here, but 
even if they didn't do revocations at all, I don't see how that affects 
security under the threat model used by the Debian packages that use on 
ca-certificates.

> As a consequence you can't trust certificates signed by StartCom before
> 2014-04-07.

This only affects certs that were used on vulnerable versions of OpenSSL 
with allocation schemes that actually loaded the private key into freed 
memory that could be returned. I haven't seen a valid claim that this is 
anywhere near a significant fraction of the web.

http://blog.erratasec.com/2014/04/why-heartbleed-doesnt-leak-private-key.html
https://twitter.com/neelmehta/status/453625474879471616

-- 
Geoffrey Thomas
https://ldpreload.com
geofft@ldpreload.com

Message #44 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: 744027@bugs.debian.org

Subject: data point

Date: Wed, 9 Apr 2014 17:01:30 -0400

[Message part 1 (text/plain, inline)]

StartSSL revoked one of my certs on request the night Heartbleed came out. I
mentioned heartbleed in the form.

However, that was a $24.90 gamble.. They could just has easily billed me.
Especially if you have a lot of different certs, that gamble may not be worth
it.

Also, I'm a paying customer, having gone through their process to get a
wildcard cert. A free customer may have different results.

And then, browsers don't check SSL cert revocations, and the infrastructure to
check reovocations is apparently broken too. So this is a gamble with not much
of a payoff.


I would be quite happy if Debian came with a way to say:
"I don't trust any cert created before heartbleed was announced."

-- 
see shy jo

[signature.asc (application/pgp-signature, inline)]

Message #49 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: Joey Hess <joeyh@debian.org>, 744027@bugs.debian.org

Subject: Re: Bug#744027: data point

Date: Wed, 9 Apr 2014 23:25:18 +0200

On Wed, Apr 09, 2014 at 05:01:30PM -0400, Joey Hess wrote:
> 
> And then, browsers don't check SSL cert revocations, and the infrastructure to
> check reovocations is apparently broken too.

The major browser do check OCSP, but they do not import CRLs.  The
CAs are supposed to be providing OCSP.

However, iceweasel/firefox by default is happy to ignore a OCSP
timeout.  You need to turn it on that it doesn't allow a timeout.
I have no idea why they use that as default.  You can change it in
edit -> preferences -> advanced -> certificates -> validation:
check both boxes.  I think by default only the first is checked.


Kurt

Message #54 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Raphael Geissert <geissert@debian.org>

To: Joey Hess <joeyh@debian.org>, 744027@bugs.debian.org

Subject: Re: Bug#744027: data point

Date: Wed, 9 Apr 2014 23:37:03 +0200

On Wednesday 09 April 2014 23:01:30 Joey Hess wrote:
[...]
> So this is a gamble with not much of a payoff.

The payoff is a certificate that is more likely not to have been 
compromised, and one that is signed by your CA.

> I would be quite happy if Debian came with a way to say:
> "I don't trust any cert created before heartbleed was announced."

Can be done if you hack X509_verify and equivalent functions when they check 
the validity of the certificate. Not that I suggest that I am going to 
implement it or that I would be in favor of such a check. I believe that it 
would be an overreaction.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net

Message #59 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Geoffrey Thomas <geofft@ldpreload.com>

To: Kurt Roeckx <kurt@roeckx.be>

Cc: Joey Hess <joeyh@debian.org>, 744027@bugs.debian.org

Subject: Re: Bug#744027: data point

Date: Wed, 9 Apr 2014 18:22:10 -0700 (PDT)

On Wed, 9 Apr 2014, Kurt Roeckx wrote:

> However, iceweasel/firefox by default is happy to ignore a OCSP
> timeout.  You need to turn it on that it doesn't allow a timeout.
> I have no idea why they use that as default.

Because it's an easy DoS if an attacker is in a position to MITM the 
connection between you and the OCSP service (or CRL file), no? And if the 
attacker can MITM the connection between you and the SSL service you're 
trying to talk to, they can probably also MITM the OCSP or CRL server.

Also (as Adam Langley points out in the stuff I linked to earlier in this 
bug report) the OCSP servers risk becoming a single point of failure if 
you do that. If a CA's OCSP server is down, everything they sign becomes 
inaccessible. That would be a bad default, and probably not something you 
want to turn on for yourself either.

Also also,
  http://www.thoughtcrime.org/papers/ocsp-attack.pdf
which appears to be still valid with Firefox at least:
  https://bugzilla.mozilla.org/505812
So there's really no value at all in using OCSP, it seems.

-- 
Geoffrey Thomas
https://ldpreload.com
geofft@ldpreload.com

Message #64 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Thorsten Glaser <t.glaser@tarent.de>

To: Geoffrey Thomas <geofft@ldpreload.com>

Cc: Klemens Baum <klemensbaum@gmail.com>, 744027@bugs.debian.org

Subject: Re: Please remove StartCom Certification Authority root certificate

Date: Thu, 10 Apr 2014 14:09:57 +0200 (CEST)

On Wed, 9 Apr 2014, Geoffrey Thomas wrote:

> This only affects certs that were used on vulnerable versions of OpenSSL with
> allocation schemes that actually loaded the private key into freed memory that
> could be returned. I haven't seen a valid claim that this is anywhere near a
> significant fraction of the web.
>
> http://blog.erratasec.com/2014/04/why-heartbleed-doesnt-leak-private-key.html

Note that this has been updated by now. See also:


   Update:  Errata  Security's  Robert Graham [12]has acknowledged that he
   was mistaken in his assessment, and that private keys could be at risk.
   The original story below has been marked up accordingly.
[…]
   In [17]a post to the Errata Security blog, Robert Graham explained that
   it  is  highly  unlikely  that  private key data would be stored in the
   memory  buffer that could be leaked using the Heartbleed exploit. “What
   you can eavesdrop on with Heartbleed hacks is dynamic stuff, stuff that
   was allocated only moments ago,” he wrote. But that assertion has been
   refuted, and Graham has since rescinded it, as noted above.
[…]
   Terrence  Koeman  of MediaMonks told Ars he found signs of attempts to
   use  the  exploit  dating  back  to  November  2013. He used the packet
   content  of  a  successful  exploit  of the Heartbleed vulnerability to
   check  inbound  packets  logged  by  his  servers and found a number of
   incoming  packets  from  a  network  suspected of harboring a number of
   “bot”  servers that were apparently scans for the vulnerability—sending
   Heartbleed-style  requests  to  two  different  development  servers in
   requests that were about five minutes apart.

[12] https://twitter.com/julianor/status/454015858042757120


By now, we must assume that private key material *can* have been leaked,
and that this was being exploited five months ago already.

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”	‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!

Message #69 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Thorsten Glaser <tg@mirbsd.de>

To: Walter Goulet <wgoulet@gmail.com>

Cc: mozilla-dev-security-policy@lists.mozilla.org

Subject: Re: Revocation Policy

Date: Thu, 10 Apr 2014 14:38:45 +0000 (UTC)

Walter Goulet dixit:

>offering. I personally have not yet decided if I will indeed revoke,

You *must* revoke.

http://arstechnica.com/security/2014/04/heartbleed-vulnerability-may-have-been-exploited-months-before-patch/
not only shows that this has been exploited since November, but also
contains a comment from the guy who said “don’t panic, it is unlikely
that private keys have leaked” yesterday, correcting himself.

See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744027

ObAmusing: switching to other implementations? Nope. OpenSSL, NSS
and the Java™ crowd are the only ones to mostly get it right.
http://pbs.twimg.com/media/Bk0DY8XCEAAPpS7.png:large

bye,
//mirabilos
-- 
<Natureshadow> Warum ist MirWebseite eigentlich so cool?  <mirabilos> weil ich
ich sie geschrieben habe  <Natureshadow> Hast du sie geschrieben oder geforkt?
<mirabilos> geschrieben, from scratch  <Natureshadow> Ach, deshalb finde ich
auch so selten Bugs dadrin. Irgendwie hast du Recht.

Message #74 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Raphael Geissert <geissert@debian.org>

To: Thorsten Glaser <tg@mirbsd.de>, 744027@bugs.debian.org

Cc: Walter Goulet <wgoulet@gmail.com>, mozilla-dev-security-policy@lists.mozilla.org

Subject: Re: Bug#744027: Revocation Policy

Date: Thu, 10 Apr 2014 17:05:59 +0200

On 10 April 2014 16:38, Thorsten Glaser <tg@mirbsd.de> wrote:
> http://pbs.twimg.com/media/Bk0DY8XCEAAPpS7.png:large

You can not expect an implementation that doesn't provide key usage
checks to, well, check key usage.

That said, even if for instance OpenSSL supports them, applications
must tell the library what they want it to check for. From a previous
look at the openssl-using applications in Debian, those cases are
rare.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net

Message #79 received at 744027-quiet@bugs.debian.org (full text, mbox, reply):

From: Thorsten Glaser <tg@mirbsd.de>

To: Pontus Engblom | DigiSSL AB <pontus.engblom@digissl.eu>

Cc: dev-security-policy@lists.mozilla.org

Subject: Re: Revocation Policy

Date: Thu, 10 Apr 2014 15:48:36 +0000 (UTC)

Pontus Engblom | DigiSSL AB dixit:

>I would like to inform you that when you get a service you tend to
>read the FAQs and Certificate Policy Statements, i.e StartSSL have a
>FAQ where a whole bunch of numbers concern revocation and handling fees.
>http://www.startssl.com/?app=25#72
>(#70 to #74). So please do not claim they do not clearly state it,
>either you didn't read or didn't care to read.

They apparently changed this practice sometime in between.
People who signed up for their service years ago did not
have any “handling fee” for revocations.

>Now they do not charge the certificate in anyway for revocation, it's
>merely a handling fee, i.e the guys that work there need to get paid
>to do their job.

I do not disagree with people needing to get their money.
I’d happily pay 5 € for certificates, and possibly a handling
fee for a revocation “on my whim”, but not acting in the face
of a security breach like this one is inacceptable (and, as
Rob Stradling pointed out, a violation of their obligations).

>I can agree that some certificates _MIGHT_ be compromised and need

No. We must assume that all private keys ever used in vulnerable
systems have been compromised; there is evidence that this has
been exploited as early as November 2013.

>revocation, but as StartSSL stated earlier, if you got no intention of
>paying $24.90 you could also create a _NEW_ certificate with a
>different subdomain and replace yours, that would cost you.. nothing?

This would help absolutely nobody because the attacker *still*
can use the private key (which they stole from you) and the
StartCom-signed certificate (which they get during the handshake
anyway) to do an MITM attack on your visitors, with StartCom
saying that the MITM attacker is “the genuine thing”.

The only option is, for example, if you have www.foo.org as
StartCom certificate, to remove A and AAAA records for both
www.foo.org. and foo.org. from the DNS, and get a certificate
for www2.foo.org – good luck getting any traffic there. And
even then, an attacker can just redirect their target’s DNS,
making the attack once again successful.

No, no matter what, those StartCom/StartSSL-issued certificates
*must* be revoked, or StartCom/StartSSL *must* be removed from
the trusted root store, no later than this Friday.

>But I can not for the life of me see why we can't pay $24.90, they
>have given us a service for free and now when we need to do something
>we think its wrong of them to charge us? Compare it to the real world,

It’s an obligation. CAs have an oligopoly and as such, they have
certain social responsibilities, for the good of the SSL ecosy-
stem as a whole.

>Also this is issue is quite hard to handle, it is unknown how many
>certs that actually have been compromised since it's not traceable.

All certificates that have been in use on systems running OpenSSL
1.x versions since the introduction of the bug and before its fix,
even if only for a fraction of a second.

>> ... - the CA obtains _reasonable evidence_ that the subscriber’s
>private key (corresponding to the public key in the certificate) has
>been compromised or is _suspected of compromise_ (e.g. Debian weak keys)"
>
>This is a bit of an issue here, we don't know whom might have been
>targeted with this bug, I find it hard that low traffic domains could

We must assume everyone has been compromised, by now. Please see my
messages to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744027
and https://bugzilla.mozilla.org/show_bug.cgi?id=994033 for sources.

>have been compromised but theres a possibility, in this case there is
>no way to get reasonable evidence of a subscriber loosing its private
>key. And to suspect every cert has been compromised well, then all CAs
>would need to make a huge CRL and pretty much revoke any certificate

Yes. (It would probably be easier to reboot the system…) But for all
we know, they need to act.

(Note that I am currently running a StartCom certificate that was
never compromised (due to only using OpenSSL 0.x) on one system,
a compromised one (which they refuse to revoke) on another system,
and a healthy mix of GoDaddy-rekeyed ones on most other systems.)

>> If the servers in your SSL environment do not use OpenSSL, if your
>servers
>> use OpenSSL 1.0.0 or earlier, if your servers do not use OpenSSL 
>> 1.0.2-beta1, or if your servers are compiled without the heartbeat
>extension
>> enabled, then your environment is not vulnerable to the Heartbleed
>> Bug attack.

Right, there’s still two years of certificates, and a stable release
of Debian, two releases of OpenBSD, and other OSes, to cover. Since
responsible admins would contact StartCom and ask for rekey/revoke
Right Now™ (or after getting back from vacation, i.e. this month,
probably), it would not be bad for them to waive their fees this
month to people citing this vulnerability. Just revoking *every*
certificate is probably a bit too much.

The important thing is to do that *right now*, and issue a statement
that they accept their responsibility for the ecosystem and will
waive fees for everyone affected. (I fully understand they will
want handling fees for “at-will” revocals normally. But this is
an exceptional situation!)

>To actually have a chance here as a CA you would need to contact every
>certificate holder and get their SSL environment. Most servers usually

You cannot access every SSL system. Things like firewalls exist.

>But as a end here, try to get a new certificate for a new subdomain if
>you can not pay $25. Or actually start to pay for SSL from the first

This does not change the fact that there are already-compromised
keys and certificates signed by a trusted CA out there, waiting
to be used (or already being used, who knows?) by attackers to
fraud by pretending false identities.

>cost. IMHO this removing of StartCom is just bogus. Maybe that Mozilla

Are you speaking for DigiSSL AB here, or just privately?

bye,
//mirabilos
-- 
<diogenese> Beware of ritual lest you forget the meaning behind it.
<igli> yeah but it means if you really care about something, don't
    ritualise it, or you will lose it. don't fetishise it, don't
    obsess. or you'll forget why you love it in the first place.

Message #84 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: Geoffrey Thomas <geofft@ldpreload.com>, 744027@bugs.debian.org

Cc: Joey Hess <joeyh@debian.org>

Subject: Re: Bug#744027: data point

Date: Thu, 10 Apr 2014 18:55:37 +0200

On Wed, Apr 09, 2014 at 06:22:10PM -0700, Geoffrey Thomas wrote:
> On Wed, 9 Apr 2014, Kurt Roeckx wrote:
> 
> >However, iceweasel/firefox by default is happy to ignore a OCSP
> >timeout.  You need to turn it on that it doesn't allow a timeout.
> >I have no idea why they use that as default.
> 
> Because it's an easy DoS if an attacker is in a position to MITM the
> connection between you and the OCSP service (or CRL file), no? And if the
> attacker can MITM the connection between you and the SSL service you're
> trying to talk to, they can probably also MITM the OCSP or CRL server.
> 
> Also (as Adam Langley points out in the stuff I linked to earlier in this
> bug report) the OCSP servers risk becoming a single point of failure if you
> do that. If a CA's OCSP server is down, everything they sign becomes
> inaccessible. That would be a bad default, and probably not something you
> want to turn on for yourself either.
> 
> Also also,
>   http://www.thoughtcrime.org/papers/ocsp-attack.pdf
> which appears to be still valid with Firefox at least:
>   https://bugzilla.mozilla.org/505812
> So there's really no value at all in using OCSP, it seems.

What we really need is OCSP stapling.  That would mean that the
server asks the CA for the OCSP response and adds that response
in the TLS session, and the client doesn't have to contact the
CA anymore to ask for the status.  Only the server would need to
contact the CA.  The server should have enough time to be able to
refresh the OCSP response, which is valid for maximum 10 days.

I'm hereing some vague cases why OCSP mandatory checking can't be
enabled by default because some users can't contact the OCSP
server.  I've never had this problem myself and I think I've seen
way to many weird setups already to not consider this a real
problem.


Kurt

Message #89 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Geoffrey Thomas <geofft@ldpreload.com>

To: Kurt Roeckx <kurt@roeckx.be>

Cc: 744027@bugs.debian.org, Joey Hess <joeyh@debian.org>

Subject: Re: Bug#744027: data point

Date: Thu, 10 Apr 2014 11:10:11 -0700 (PDT)

On Thu, 10 Apr 2014, Kurt Roeckx wrote:

> What we really need is OCSP stapling.  That would mean that the
> server asks the CA for the OCSP response and adds that response
> in the TLS session, and the client doesn't have to contact the
> CA anymore to ask for the status.  Only the server would need to
> contact the CA.  The server should have enough time to be able to
> refresh the OCSP response, which is valid for maximum 10 days.

Yes, agreed. Unfortunately not many sites enable it. I think it'd be 
productive to have Debian-packaged SSL _servers_ all support and document 
and maybe default to OCSP stapling, so that in a few years, maybe we can 
have the start of a working revocation protocol. Sadly, there isn't one 
right now, so I don't there's anything we can do today.

This documentation seems to imply that upstream Apache HTTPD does not 
usefully support stapling when intermediate certs are in play, which is 
basically always:

https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslusestapling

> I'm hereing some vague cases why OCSP mandatory checking can't be
> enabled by default because some users can't contact the OCSP
> server.  I've never had this problem myself and I think I've seen
> way to many weird setups already to not consider this a real
> problem.

Well, you'll have the problem as soon as you're being MITM'd. A cert 
verification solution that works fine when nobody's MITMing you is not 
particularly useful. :-)

-- 
Geoffrey Thomas
https://ldpreload.com
geofft@ldpreload.com

Message #94 received at 744027@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: Geoffrey Thomas <geofft@ldpreload.com>

Cc: 744027@bugs.debian.org, Joey Hess <joeyh@debian.org>

Subject: Re: Bug#744027: data point

Date: Thu, 10 Apr 2014 20:38:21 +0200

On Thu, Apr 10, 2014 at 11:10:11AM -0700, Geoffrey Thomas wrote:
> On Thu, 10 Apr 2014, Kurt Roeckx wrote:
> 
> >I'm hereing some vague cases why OCSP mandatory checking can't be
> >enabled by default because some users can't contact the OCSP
> >server.  I've never had this problem myself and I think I've seen
> >way to many weird setups already to not consider this a real
> >problem.
> 
> Well, you'll have the problem as soon as you're being MITM'd. A cert
> verification solution that works fine when nobody's MITMing you is not
> particularly useful. :-)

So if I'm understanding it right, we're not checking OCSP because
the check might fail when there is a MITM attack, and we want to
pretend nothing is going on in that case?  That looks like a very
good reason.


Kurt

Message #101 received at 744027-done@bugs.debian.org (full text, mbox, reply):

From: Michael Shuler <michael@pbandjelly.org>

To: 744027-done@bugs.debian.org

Subject: Re: Bug#744027: Please remove StartCom Certification Authority root certificate

Date: Sun, 05 Oct 2014 20:48:02 -0500

Closing bug.

Send a report that this bug log contains spam.