It's worth noting that StartCom isn't actually a free CA. They've
demonstrated that with the business model they're using.
On Mon, Apr 21, 2014 at 6:18 PM, Peter Eckersley wrote:
> Removing Startcom from the trust root would be a catastrophe for the
> security of Mozilla's users, since it would
Removing Startcom from the trust root would be a catastrophe for the
security of Mozilla's users, since it would move the Web from one free CA
to zero free CAs, thereby forcing over a hundred thousand websites from
HTTPS (which is actually still not terrible, even if you had a window of
Heartbleed
On 21/04/14 08:50 PM, Radu Hociung wrote:
> On Monday, April 21, 2014 12:32:43 PM UTC-4, Daniel Micay wrote:
>> Mozilla has all the
>> cards in their hands here.
>
> Indeed. I'm glad to see others before me reached the same conclusion, that
> the appropriate response is to remove the trusted stat
On Monday, April 21, 2014 12:32:43 PM UTC-4, Daniel Micay wrote:
> Mozilla has all the
> cards in their hands here.
Indeed. I'm glad to see others before me reached the same conclusion, that the
appropriate response is to remove the trusted status of Startcom.
The original bugzilla #994033 was c
That would have the {justifiable,entertaining,controversial} result of
causing any captive portal that uses HTTPS in captivity to fail. Sounds
like an interesting proposal if you can persuade all the browsers to do it
simultaneously, but if Mozilla does it in isolation, it would unfortunately
just
On 21/04/14 01:12 PM, Phillip Hallam-Baker wrote:
> Given the current Heartbleed situation, wouldn't it be appropriate to
> turn on hard fail for revocation checking so that unknown status
> results in the cert being rejected.
Using hard fail for revocation checking means a DoS of *many* sites jus
Given the current Heartbleed situation, wouldn't it be appropriate to
turn on hard fail for revocation checking so that unknown status
results in the cert being rejected.
I am seeing people suggest that a CA be dropped from the root for
their alleged improper handling of revocation. If revocation
On 16/04/14 09:52 PM, Radu Hociung wrote:
> Greetings,
>
> I believe the presence of Startcom's root CA enables much of the Internet
> user population to be MITM'd via pkeys leaked (due to the Heartbleed bug),
> whose owners won't pay Startcom to revoke their respective certs.
>
> The decision
On 18/04/14 05:32 AM, tyler.sz...@gmail.com wrote:
> Would it be feasible for Mozilla to maintain a CRL-like that sidesteps the
> need for the CA to revoke a cert?
>
> This way if a CA is behaving badly the certificate still gets invalidated.
I think it would be a lot saner to simply stop showin
I checked customers on official site of Wosign
https://www.wosign.com/
It seems wosign have 3 different certificate using same Key-pair(Have same
public key)
that is :
1,Certification Authority of WoSign as a subCA under Wosign 1999
example customer Url:
https://person.guilinbank.com.cn/
2,Cert
The way I see it, this is a clear violation of the Mozilla CA Certificate
Maintenance Policy!
If such a violation has no consequence at all for the CA, what example would
that be?
Wouldn't it encourage all CAs to ignore the policy in the future?
I see it this way:
StartSSL violates the policy, so
This description by Jeremy Gosni about how he cracked CloudFlare's challenge
makes grabbing a private key sound much easier than thought:
https://gist.github.com/epixoip/10570627
I admit I don't 100.0% follow the approach, but it hinges on looking for the
actual p and q prime factors in memory,
Would it be feasible for Mozilla to maintain a CRL-like that sidesteps the need
for the CA to revoke a cert?
This way if a CA is behaving badly the certificate still gets invalidated.
___
dev-security-policy mailing list
dev-security-policy@lists.mozill
I think pay-to-revoke is pretty bad for security, and therefore should not be
allowed.
I also think it's unnacceptable for a CA not to care that they have a green
padlocks around that don't mean what they're supposed to -
like Startcom is doing, they've received revocation requests, but they ar
Hello,
Am Donnerstag, 10. April 2014 16:28:38 UTC+2 schrieb Rob Stradling:
> The Mozilla CA Certificate Maintenance Policy (Version 2.2) [1] says
> "CAs _must revoke_ Certificates that they have issued upon the
>
> occurrence of any of the following events:
>
> ...
>
>- the CA obtains _r
On Saturday, April 12, 2014 9:27:24 AM UTC+2, Jürgen Brauckmann wrote:
> Cloudflare set up a challenge with nginx on Ubuntu. Seems some
>
> people succeeded in extracting the servers private key:
I think thats enough evidence that Heartbleed really did leak private keys.
What to do next? It seem
On Thursday, April 10, 2014 6:47:38 PM UTC-5, Peter Eckersley wrote:
> I think one large and tricky open question here is what the standard for
>
> "suspected of compromise" is.
>
>
This is neither large nor tricky, for two reasons.
Firstly, look at the exact wording:
> the CA obtains reasona
Greetings,
I believe the presence of Startcom's root CA enables much of the Internet user
population to be MITM'd via pkeys leaked (due to the Heartbleed bug), whose
owners won't pay Startcom to revoke their respective certs.
The decision to not revoke is an economic one for most customers of t
I did this as a test:
https://revokame.tonylampada.com.br/
Given Startcom reply to it, it seems pretty clear to me that they are in
violation of CA policy, they are already hurting the security of the internet
and the internet should not trust them anymore.
On Saturday, April 12, 2014 9:42:
19 matches
Mail list logo
