On Sep 16, 2014, at 7:54 PM, Paul Wouters <paul(_at_)nohats(_dot_)ca> wrote:
On Tue, 16 Sep 2014, David Conrad wrote:
I believe a client gets thrown to a CAPTCHA when the source IP address is
identified with a threat/attack of some sort in order to ensure there is a
human behind the client. In as much as sites behind Tor are used to
originate attacks, it isn’t too surprising that they get redirected to a
CAPTCHA.
As for it being sad, I see it as a reasonable tradeoff in today’s Internet.
How many attacks has ietf.org been under? Can the vendor not distinguish
between tor nodes towards ietf.org and tor nodes towards other sites? We
have contributors in countries where using tor to access IETF might
actually be a requirement.
How does this mechanism work when there is traffic using TLS? Is there a
MITM cert?
No. They present a perfectly valid certificate for *.ietf.org signed by
Starfield.
So the delegation is done by CNAME record for HTTP and by a certificate for
TLS. A typical CDN server is likely to store dozens or hundreds of such private
keys and certificates. This was discussed at the DANE meeting in Toronto (and
the minutes show you were there).
Few things in life are. I imagine if another company were to provide a
better deal/meet the IETF requirements for CDN services, the IETF would
probably switch.
I would hope IETF would pick a CDN provides that does not require
insecure CNAME redirection which breaks some of our IETF protocols
(like DANE). Hopefully, they will address that soon.
Your browser has to get to the CDN server somehow. If not a CNAME, you’ll need
to just let www.ietf.org resolve directly to that server. How is that better?
Yoav