[cabf_validation] Notes of Meeting Held 10-August-2017 - Discussion of Redirects

Ben Wilson ben.wilson at digicert.com
Sun Aug 27 14:42:44 MST 2017


Here are the notes from our meeting held August 10, 2017.  (When we
discussed re-directs)

 

Present:  Doug Beattie, Ben Wilson, Rick Andrews, Wayne Thayer, Rich Smith,
Steve Medin, Tim Hollebeek, Wendy Brown, Kirk Hall, Tim Shirley, Peter Bowen

 

Kirk's version 6 of Ballot 190 was ready to go, but he wanted to incorporate
the changes that the revisions to Ballot 202 were going to make.  Ben was
waiting on Peter to finalize the post-Ballot-202 version.  There is a
general concern about compliance, given that Mozilla's deadline for
compliance with BR v. 1.4.1 was in July.  Steve said there may be momentum
to push something through if we know we'll talk about random number reuse in
the future.  There was discussion that Ballot 190 has an effective date, and
waiting would push out change coding with a hold on the effective date in
future.  Peter joined the call and said that he had received feedback -- why
should we allow underscores at all?  This caused concern about further
delay.  

 

There was a question about Mozilla's position, given that Mozilla requires
v. 1.4.1 methods, how will Mozilla handle changes based on Ballot 190?  It
was stated that Mozilla was principally trying just to stop CAs from using
"any other method."

 

Peter explained that his proposal for Ballot 190 allowed reuse as long as it
was collected before date X.  Kirk said that under his proposal a CA
wouldn't have go back and re-perform validation unless a new ballot says
they have to. 

 

There was a discussion of redirects and the group noted that the proposals
are currently silent on redirects.  Steve said that because we don't
prohibit it, we allow it, and it happens.  

 

Tim H. said that, in his opinion, the BRs can be read both ways.  One
interpretation is that the validation method just says retrieve the web
page, and doesn't say you can follow redirects, therefore you can't.  The
other interpretation is that following redirects is implicitly part of
"retrieving a web page".

Peter and Rick discussed meta-refresh issues and Tim H. said that meta
refresh issues were a concern that he hadn't considered.  Peter was
concerned about java script redirects when humans are involved in performing
validation as opposed to machine processing.  

 

The group agreed that we want to allow redirect from port 80 to port 443, or
another port on the  port list, otherwise, why have an approved port list?

 

Peter asked whether a redirect from www.example.com to example.com should be
allowed.  Steve noted that someone with control of base domain can cause the
base domain to be the authorization domain name.  Peter asked, what about
the reverse? 

 

There was discussion about sending a 301 code and the different methods of
redirects and Tim H. said that meta refreshes really bothered him. 

 

Steve noted a problem with allowing redirects in WordPress pages.

 

Peter said there seemed to be consensus that following ([Rick] port-only
redirects from 80 to 443 or vice-versa on the same FQDN were acceptable)
then the host name portion of the new URL ([Rick] Not sure what the last
part was about).

 

Kirk asked which validation methods are most effected.  The response was
that it was only Method 6, "Agreed-Upon Change to a Web Site."  

 

Steve said that he would play Devil's Advocate and argue that if you have
enough control of ([Rick] the web server to set up a redirect to another
destination) and that other destination  ([Rick] has the Random Value that
you're looking for) and there is risk . . . could be proof of ownership and
control of a different domain, when launching a new . . . in order to get a
certificate, you have to do at a secret .

 

Wayne said we should just write up what we think is a reasonable approach,
and put it out on the list to discuss more.

 

Rich Smith argued that when dealing with security, the requirements should
be written from the position of "Default Deny."  There are enough domain
validation methods now that our default should be default deny, not default
allow. If it doesn't affect security, write them in as specifically allowed.

 

Steve noted that a lot of CAs follow HTTP redirects.  Steve also noted that
there are situations where the customer needs to do it privately, where they
don't want the domain exposed except to a limited number of authorized
people, and they can't do high speed issuance without allowing redirects.

 

There was a question about Let's Encrypt/ACME.  They use file-based control
as their major method.  Rich said that Comodo uses it too.  There was a
question from the group about gathering data from CAs on how many redirects
they encounter when performing domain validation.  Rich said he could ask
Rob and Robin and find out.  He said we should post something on the general
list.  Maybe Let's Encrypt will explain how it follows re-directs. 

 

Kirk asked why, if you send the customer a random value and it appears where
you go to check it, why you would care about redirects and a man in the
middle.  Steve said that it is because there may have been impermissible
hops that have been created.  What if Google decides to put malicious java
script in googlefonts.com?  Someone using it would get additional page
content . . . they could inject a time bomb in java script, using names of
customers to do validation, etc.

 

Wayne said, whatever we do, we need feedback. We need to put a proposal out
there.

 

Kirk asked whether the CA would know it had been redirected.  Steve said it
depends on your code and how you've built your CA validation system. 

 

Tim H. and Peter discussed HTTP libraries that don't handle these redirects,
so with automation they won't be affected, they wouldn't follow these
redirects.  They said that most HTTP libraries will follow 301 redirects
unless told not to, but will not follow javascript or meta refresh.  Tim. H.
mentioned that he expected that the current behavior of many CAs probably
reflects the default behavior of their chosen library, rather than explicit
choice by the CA about their redirect policy.

 

Rich said that our proposed language should say, "redirects, unless
expressly allowed below, are prohibited."  Let anyone who wants to allow a
particular type of redirect make their case for it.

 

Kirk asked Wayne if he could put a straw-man out for discussion and see what
kind of reaction we get.

 

Wayne said that GoDaddy checks Ports 80 and 443 independently (without
following a redirect but detecting whether there has been a redirect). 

 

Kirk said that he would work with Ben and Peter on getting a version of
Ballot 190 ready. 

 

Meeting adjourned.

 

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20170827/25aedb3f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 6104 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20170827/25aedb3f/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4974 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20170827/25aedb3f/attachment-0001.p7s>


More information about the Validation mailing list