First of all: Thanks for the transparency, the detailed report and quick
response to this incident.
A user on Hacker News brought up the possibility that the fairly popular
DirectAdmin control panel might also demonstrate the problematic
behaviour mentioned in your report[1].
I successfully repro
Until November 11, 2015, publicly-trusted CAs were allowed to issue
certificates for internal names and reserved IP addresses. All
certificates of this nature had to be revoked by October 1, 2016.
More details here: https://cabforum.org/internal-names/
Patrick
On 09.12.17 20:42, Lewis Resmond vi
On 28.09.17 19:06, Gervase Markham via dev-security-policy wrote:
> On 26/09/17 03:17, Ryan Sleevi wrote:
>> update in a year, are arguably outside of the scope of ‘reasonable’ use
>> cases - the ecosystem itself has shown itself to change on at least that
>> frequency.
>
> Is "1 year" not a relat
On 21/09/2017 23:08, alejandrovolcan--- via dev-security-policy wrote:
> Dear Gerv, I have attached a document that gives us a greater
> response to each of the points, as well as Mr. Oscar Lovera sent you
> an email with the same information
>
> https://www.dropbox.com/s/qowngzzvg5q5pjj/Mozilla%2
On 19/09/2017 14:59, Gervase Markham via dev-security-policy wrote:
> It might also be worth thinking about the value that DNSSEC adds, over
> and above a non-secure CAA check, in various attack scenarios. At the
> moment, I'm thinking that DNSSEC doesn't necessarily add much. Here are
> 3 quick sc
In what way would this be a policy violation? Most CAs trusted by
Mozilla issue wildcard certificates.
Perhaps you were thinking of EV certificates? For EV, wildcard is indeed
not permitted, but Let's Encrypt does not issue EV at all.
On 29/08/2017 04:31, David E. Ross via dev-security-policy wro
On 03/08/2017 10:47, Inigo Barreira via dev-security-policy wrote> 1.
The un-revoked test certificates are those pre-sign ones with uncompleted
> ctlog. So they are not completed certificates.
> https://crt.sh/?opt=cablint&id=134843670
> https://crt.sh/?opt=cablint&id=134843674
> https://crt.sh/?op
On 13/02/2017 18:25, Ryan Sleevi via dev-security-policy wrote:
> On Mon, Feb 13, 2017 at 8:17 AM, Steve Medin via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Getting all user agents with interest is issuance limits to implement the
>> CA Issuers form of AIA for dyna
On 13/02/2017 16:15, Jürgen Brauckmann via dev-security-policy wrote:
> Gervase Markham via dev-security-policy schrieb:
>> 1) As with all CAs, update all their domain validation code to use one
>> of the 10 approved methods;
>
> I'm probably confused regarding BRs pre/post Ballot 181: Aren't ther
On 07/02/2017 08:11, Tom wrote:
> Le 07/02/2017 à 05:01, Patrick Figel a écrit :
>> On 27/01/2017 19:53, Ryan Sleevi wrote:
>>> On Fri, Jan 27, 2017 at 3:47 AM, Gervase Markham
>>>
> wrote:
>>>>
>>>> * RSA keys with a minimum modulus size
On 27/01/2017 19:53, Ryan Sleevi wrote:
> On Fri, Jan 27, 2017 at 3:47 AM, Gervase Markham wrote:
>>
>> * RSA keys with a minimum modulus size of 2048 bits
>>
>
> Nits and niggles: Perhaps 2048, 3072, 4096?
>
> - 8K RSA keys cause Web PKI interop problems
> - RSA keys that aren't modulo 8 create
On 11/01/2017 19:06, Nick Lamb wrote:
> For those who haven't (unlike Patrick) sat down and read the ACME
> specification, ACME http-01 won't get tripped here because the
> checked content of the URL is very much not the random string (it's a
> JWS signature over a data structure containing that ra
On 11/01/2017 16:55, Paul Wouters wrote:
> Are you saying that for an unknown amount of time (years?) someone
> could have faked the domain validation check, and once it was
> publicly pointed out so everyone could do this, it took one
> registrar 10 months to fix, during which 8800 domains could
On 11/01/2017 04:08, Ryan Sleevi wrote:
> Could you speak further to how GoDaddy has resolved this problem? My
> hope is that it doesn't involve "Only look for 200 responses" =)
In case anyone is wondering why this is problematic, during the Ballot
169 review process, Peter Bowen ran a check again
On Tue, Nov 22, 2016 at 10:56 PM, Tobias Sachs wrote:
> Am Dienstag, 22. November 2016 21:37:08 UTC+1 schrieb Lewis Resmond:
>> Hello,
>>
>> I just noticed following announcement by WoSign:
>>
>> https://www.wosign.com/english/News/certificate_pre.htm
>>
>> If I understand correctly, they now have
On 03/11/16 10:59, Gervase Markham wrote:
> However, I still don't get why you want to use Cloudflare's SSL
> termination services but are unwilling to allow them to get a
> certificate for your domain name.
>
> AIUI their free tier uses certs they obtain, but if you pay, you can
> provide your ow
I found a number of SHA-1 certificates chaining up to CAs trusted by
Mozilla that have not been brought up on this list or on Bugzilla yet.
Apologies in case I missed prior discussion for any of these, and kudos
to censys for making this search incredibly easy.
#1
https://crt.sh/?id=32335005&opt=c
On 26/10/16 01:27, Percy wrote:
> WoSign will roll out a globally trusted intermediate cert to sign new
> certs with the existing WoSign system that had so many control
> failures.
>
> Does Mozilla and this community accept such a work-around for WoSign?
> If we do, then what's the point of distru
On 07/10/16 13:23, Jakob Bohm wrote:
> On 07/10/2016 13:12, Gervase Markham wrote:
>> ... * WoSign agrees it should have been more forthcoming about its
>> purchase of StartCom, and announced it earlier.
>>
>> * WoSign and StartCom are to be legally separated, with the
>> corporate structure chang
On 02/10/16 12:01, Jason Milionis wrote:
> Still no response from COMODO CA, that's interesting, but why?
They published an incident report a couple of days ago. For some reason,
it's not visible in the Google Groups archive of m.d.s.p (at least for
me). Here's an alternative link:
https://www.ma
On 17/09/16 16:38, Florian Weimer wrote:
> * Peter Bowen:
>
>> On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei
>> wrote:
>>> So when I delegated the DNS service to Cloudflare, Cloudflare
>>> have the privilege to issue the certificate by default? Can I
>>> understand like that?
>>
>> I would guess
On 11/09/16 22:05, Lee wrote:
>> In order to spoof a CA's domain validation request, an attacker
>> would need to be in a position to MitM the connection between the
>> CA and the targeted domain.
>
> does dns hijacking or dns cache poisoning count as mitm?
I was mentioning this in order to demon
On 10/09/16 22:37, Lee wrote:
> Right - I figured that out about 30 seconds after reading an email
> about allowing verification on ports 80 and 443. But you only need
> to get the initial certificate one time - after that you should be
> able to renew using port 443 and I didn't see anything i
On 03/09/16 01:15, Matt Palmer wrote:
> On Fri, Sep 02, 2016 at 03:48:13PM -0700, John Nagle wrote:
>> On 09/02/2016 01:04 PM, Patrick Figel wrote:
>>> On 02/09/16 21:14, John Nagle wrote:
>>>> 2. For certs under this root cert, always check CA's
>>>>
On 02/09/16 21:14, John Nagle wrote:
> 2. For certs under this root cert, always check
>CA's certificate transparency server. Fail
> if not found.
To my knowledge, CT does not have any kind of online check mechanism.
SCTs can be embedded in the certificate (at the time of issua
Richard,
the problem with this approach is that the *subscriber* might not be
authorized to make this decision for the parent domain. To go back to
the GitHub case, the "owner" of a github.io subdomain telling you that
they are authorized to own a certificate that covers github.io is
irrelevant, a
On 20/07/16 04:59, Peter Kurrasch wrote:
> Regarding the on-going development of the spec: I was thinking more
> about the individual commits on github and less about the IETF
> process. I presume that most commits will not get much scrutiny but
> a periodic (holistic?) review of the doc is expec
Before getting into specifics, I should say that you're likely to get a
better answer to most of these question on the IETF ACME WG mailing list[1].
On 08/07/16 16:36, Peter Kurrasch wrote:
> I see on the gitub site for the draft that updates are frequently
> and continuously being made to the pro
On 08/07/16 08:04, Peter Gutmann wrote:
> Or is it that ACME is just a desperate attempt to derail StartCom's
> StartEncrypt at any cost?
That doesn't make any sense - ACME has been in production for close to a
year, while StartAPI was launched this April (and StartEncrypt just a
couple of weeks a
On Friday, July 1, 2016 at 9:35:20 AM UTC+2, Eddy Nigg wrote:
> So far less than three hundred certificates have been issued using
> this method, none should have been effectively issue wrongfully due
> to our backend checks.
Can you comment on how your backend checks would have prevented any
misi
30 matches
Mail list logo
