Re: Security concern on various domain validating methods

2016-09-12 Thread Stephen Schrauger
On Friday, September 9, 2016 at 11:13:49 AM UTC-4, Han Yuwei wrote:
> 在 2016年9月9日星期五 UTC+8上午12:00:15,Stephen Schrauger写道:
> > Regarding the specific file verification method:
> > 
> > It proves you control the web server that runs under the domain. Which is 
> > more or less all that you need to prove, since a TLS certificate is 
> > designed for web security. 
> > 
> > If you don't control DNS, but you do control the web server, you 
> > essentially control the domain as far as web browsing goes, and thus you 
> > should be able to acquire a certificate for that domain. Which is probably 
> > why it is included in the Baseline Requirements as an acceptable validation 
> > method.
> 
> My concern is there could be multiple website deployed on one host. So the 
> host admin could issue a cerificate for a domain. Since the vaildate period 
> is typically 1 year or more, It's a securiry concern if domain owner have 
> changed the record but the certficate didn't revoked.

Yes, the host admin has that ability. They also have the ability to modify the 
website in general. Anytime you use a hosted service, you have to trust the 
server admins. Being able to get a certificate is the least of the website 
owner's worries.

As far as validation periods go, this is true for any certificate on any 
domain. I could get a certificate for my domain today, valid for 3 months or 3 
years, and then tomorrow transfer the domain to someone else. I still have a 
certificate, and I don't control the domain anymore. This is a non-issue, since 
nothing could feasibly prevent such a scenario.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Security concern on various domain validating methods

2016-09-08 Thread Ryan Sleevi
On Thursday, September 8, 2016 at 9:00:15 AM UTC-7, Stephen Schrauger wrote:
 > It proves you control the web server that runs under the domain. Which is 
 > more or less all that you need to prove, since a TLS certificate is designed 
 > for web security. 
> 
> If you don't control DNS, but you do control the web server, you essentially 
> control the domain as far as web browsing goes, and thus you should be able 
> to acquire a certificate for that domain. Which is probably why it is 
> included in the Baseline Requirements as an acceptable validation method.

Just a slight correction: TLS is not only used for HTTPS. We certainly know 
it's used for other protocols - such as IMAPS and POPS - and we know that a 
given service may be colocated with other services on the same host. At 
present, a TLS certificate doesn't distinguish the intended or authorized 
services (there's a SRVName ballot circulating in the Forum that could resolve 
this), but I think recent events have shown the issues where control of a 
single service might be elevated to presumptive control of the domain, which 
can and, in the case of mail providers, frequently is, inaccurate.

That is, consider the example of StartCom and WoSign including 'base domains' 
within the certificate (both authorized and unauthorized), where a certificate 
for 'mail.example.com' would include a SAN of 'example.com'. Just because I can 
demonstrate operational control of 'mail.example.com' (for example, if 
mail.example.com was actually run by GMail) doesn't imply authorization of 
'example.com'.

This is, perhaps, a convoluted example, but it's meant to highlight why, for 
the methods of control that don't directly rely upon DNS, the intended 
authorization scope in the new validation methods is limited to the FQDN of 
that host (e.g. the cert could only contain mail.example.com), which was 
already a requirement in previous versions, but made more explicit in the 
latest versions. However, control of the web portion of mail.example.com 
doesn't imply control of the email portion, and that's where the SRVName ballot 
fits.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Security concern on various domain validating methods

2016-09-08 Thread Stephen Schrauger
Regarding the specific file verification method:

It proves you control the web server that runs under the domain. Which is more 
or less all that you need to prove, since a TLS certificate is designed for web 
security. 

If you don't control DNS, but you do control the web server, you essentially 
control the domain as far as web browsing goes, and thus you should be able to 
acquire a certificate for that domain. Which is probably why it is included in 
the Baseline Requirements as an acceptable validation method.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Security concern on various domain validating methods

2016-09-07 Thread Ryan Sleevi
On Wednesday, September 7, 2016 at 10:43:34 AM UTC-7, Han Yuwei wrote:
> I raise this question because of the Wosign's incident about high port 
> validating. Many CA use email validating such as send a email to 
> webmas...@foo.bar, or put a specific file into the root of website.
> What I think is that this cannot validate *domain* is yours.  It just 
> verified you have the mail server or you control the host. The best way to 
> prove you own a domain is to change the DNS records of the domain.
> So I suggest to change domain validating method to verify DNS records. Is 
> that feel better?

Hi,

It sounds like you may not be familiar with the Baseline Requirements, which 
specifically spell out how to validate domains - 
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.9.pdf

This already covers the specific set of email addresses that are 
reserved/acceptable to be used, the methods of file based validation, and other 
forms of DNS record-based validation. This was the result of a nearly 2 year 
effort to strengthen the requirements, and while it's far from being as rock 
solid as we might want, it hopefully provides a better path to prevent many of 
the mistakes made.

To understand specifically what changed recently, perhaps review 
https://cabforum.org/2016/08/05/ballot-169-revised-validation-requirements/

If you have any further concerns, you could certainly raise them to the 
CA/Browser Forum - questi...@cabforum.org - or by signing up as an Interested 
Party, as explained at https://cabforum.org/email-lists/ and in the Forum's 
Bylaws - but it's likely that you would find many concerns have already been 
discussed or are in the process of being discussed.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Security concern on various domain validating methods

2016-09-07 Thread Han Yuwei
I raise this question because of the Wosign's incident about high port 
validating. Many CA use email validating such as send a email to 
webmas...@foo.bar, or put a specific file into the root of website.
What I think is that this cannot validate *domain* is yours.  It just verified 
you have the mail server or you control the host. The best way to prove you own 
a domain is to change the DNS records of the domain.
So I suggest to change domain validating method to verify DNS records. Is that 
feel better?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy