pfg

54 ms·

481.
by pfg 10y ago
Are you implying nation states are going to prevent browser vendors from implementing mandatory Certificate Transparency? Why haven't they done that for HPKP, which would allow ISIS to prevent being MitM'd as well? What about all
482.
by pfg 10y ago
I'm not sure which part of my reply you think is not possible - if it's the "guaranteed transparency" bit, that is very much possible and is the end-goal for Certificate Transparency. There is no way to "bypass&quot
483.
by pfg 10y ago
I honestly don't think the location should be a factor. How many countries are there that don't have things like national security letters? I'd rather have a system where the same criteria apply to all CAs independent of thei
484.
by pfg 10y ago
I'm sure plenty of "western" sites have attempted to get similar deals (FWIW, Tyro, one of the companies that got SHA-1 certificates from WoSign, is based in Australia), but I'm not aware of any other CA incidents like t
485.
by pfg 10y ago
A common approach is to get SHA-1 certificates signed by roots that have been pulled from various root programs, but are still (likely) present on outdated devices that do not support SHA-2 (like XP <= SP2). I think CloudFlare is using o
486.
by pfg 10y ago
> And btw you shouldn't let your extensions auto-update on Firefox anyway, specially if you use Tor, as it's vulnerable to MITM as someone posted here a few days ago. This was fixed in Tor Browser 6.0.5[1] and Firefox 49[2]. Wo
487.
by pfg 10y ago
This announcement only pertains to the "WoSign CA Free SSL Certificate G2" intermediate CA and does not affect any StartCom-issued certificates. They might announce similar steps for StartCom in the future, but nothing as of yet.
488.
by pfg 10y ago
A number of issues can be found here[1]. Among other things, they allowed domain validation on unprivileged ports and issued certificates for "parent" domains when subscribers were able to validate control of a subdomain (i.e. you
489.
by pfg 10y ago
There were a number of other issues that came up during this investigation that showed that they should not be running a CA[1]. For example, they issued certificates to anyone able to control a unprivileged port (> 1024) behind a domain.
490.
by pfg 10y ago
That's in all likelihood the same issue - Qihoo de facto owning two CAs who currently cast two separate votes in the CA/B Forum. Not sure if it would be a concern otherwise (i.e. if Qihoo were to own just one CA and not disclose t
491.
by pfg 10y ago
WoSign supposedly logged all certificates they issued to various Certificate Transparency log servers, so domain owners could check those records for any mis-issuance. There probably aren't too many organizations who check CT regularly
492.
by pfg 10y ago
IIRC WoSign was never in Apple's trust store in the first place; their trust status came from StartCom cross-signing their certificates. (Not sure if cached intermediate certificates get added to the keychain - maybe that's what y
493.
by pfg 10y ago
The issue you're describing is a concern for the CA/B Forum, not really all that relevant for Mozilla/mozilla.dev.security.policy. That being said, the CA/B Forum seems to be discussing the issue[1]. [1]: https:/&#
494.
by pfg 10y ago
It's possible to determine whether a client supports certificates using SHA-2 by analyzing the ClientHello and use that to switch between a SHA-1 and SHA-2 certificate. CloudFlare[1] and some of the bigger sites like Facebook have done
495.
by pfg 10y ago
If that's possible, I'm sure you'll have no difficulty finding a public source to cite that states the same.
496.
by pfg 10y ago
As both rockdoe and hannob have mentioned, ed25519 provides the same attack resistance as a 128-bit symmetric cipher. This is even mentioned in the original DJB ed25519 paper: > High security level. This system has a 2^128 security targe
497.
by pfg 10y ago
DNS might still be propagating. krebsonsecurity.com pointed to 127.0.0.1 while the site was offline.
498.
by pfg 10y ago
There's a "server: shield" response header for krebsonsecurity.com, so this is probably a good guess.
499.
by pfg 10y ago
That's not what your own source says about 128-bit symmetric keys: > Long-term protection > Generic application-independent recommendation, protection from 2016 to 2040
500.
by pfg 10y ago
Many of the clients above support something like certbot's webroot plugin, which is web server-agnostic and works by simply putting a verification file in your webroot and serving that to Let's Encrypt's validation server. Al
501.
by pfg 10y ago
Good point, that makes more sense.
502.
by pfg 10y ago
Not necessarily. The article mentions phones being paired with iTunes - I assume this involves entering the passcode on the phone (haven't used iTunes for my phone in years, so I'm not entirely sure, but by my understanding of the
503.
by pfg 10y ago
The article seems to suggest that an attacker would be able to perform a (new) backup without unlocking the phone if they had access to a "pairing record from a trusted computer", which I assume means an iTunes installation that&#
504.
by pfg 10y ago
The warrant in question is one that allows them to deploy the NIT in order to get the IP addresses in the first place. They wouldn't know these addresses prior to deploying the NIT, so there's no way they'd be able to get a w
505.
by pfg 10y ago
AIUI this affects the code that handles the TLS extension with which a client tells the server that it supports OCSP stapling, so any server with an affected openssl version would be vulnerable.
506.
by pfg 10y ago
There are a number of client options for windows[1]. [1]: https://letsencrypt.org/docs/client-options/#windows
507.
by pfg 10y ago
The research paper[1] has more details. AIUI, knowing the client certificate's private key allows the attacker to calculate the TLS master secret if the server supports a non-ephemeral (EC)DH cipher and the attacker has access to a val
508.
by pfg 10y ago
Note that this attack was published about a year ago. (It's only mentioned in the footer, so might be easy to miss.)
509.
by pfg 10y ago
> And as long as HTTP works so fine for all Amazon e-commerce websites "beside their US centric Amazin.com" (as I wrote, but some didn't get) I've checked amazon.de, amazon.co.uk, amazon.fr, amazon.ca and amazon.de,
510.
by pfg 10y ago
> They don't, they differ widely. Some go much further than simply DNS validation. You're missing my point. You're acting like adding yet another DNS query equals some massive increase in complexity. However, all certifi

More ›