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 thi
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
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.
>
> B
On 10 April 2014 16:38, Thorsten Glaser 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 wh
lso
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 o
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 f
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
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
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.
H
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, h
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
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
>
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 certai
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
Start
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 compromi
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
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 (
17 matches
Mail list logo
