[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Letsencrypt and Tor Hidden Services



Im wondering , have anyone got letsencrypt to work with a .onion site? Or is it jus clearnet

Alec Muffett <alecm@xxxxxx> skrev: (19 augusti 2015 20:43:53 CEST)
>Pardon me replying to two at once...
>
>
>> On Aug 19, 2015, at 18:34, Seth David Schoen <schoen@xxxxxxx> wrote:
>> 
>> [...]
>> Right now, the industry allows .onion certs temporarily, but only EV
>> certs, not DV certs (the kind that Let's Encrypt is going to issue),
>> and the approval to issue them under the current compromise is going
>> to expire
>
>
>...or perhaps not...
>
>
>> It's seemed like the efforts at IETF to reserve specific
>"peer-to-peer
>> names" would be an important step in making it possible for CAs to
>issue
>> certs for these names permanently.  These efforts appeared to get
>somewhat
>> bogged down at the last IETF meeting.
>
>
>Hi, I'm Alec, and I am co-author of the Onion RFC draft with Jacob
>Appelbaum.
>
>Reports of the bogging-down have been greatly exaggerated, and I wish
>people would stop repeating them.
>
>The status of the Onion RFC draft is viewable at:
>
>https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/
>
>...and this afternoon I created some amendments to the draft to address
>IETF and IANA concerns, and have circulated them amongst the team (me,
>Jake, Mark) to see if I've goofed.
>
>We will merge them, soon, in good time for the next review.
>
>In the most recent review IANA in particular were very helpful,
>offering to rewrite some of their stuff in order to make it abundantly
>clear to CA/B-Forum that:
>
>1) onion will be a special case
>2) onion should never be delegated
>3) but nonetheless SSL certificates should be issued for it
>
>...which proactively addresses a concern from a few months back re:
>whether CA/B-Forum would nitpick a "Special Use" designation.
>
>
>TL;DR - we are not past the finish line yet, and there is work to be
>done and challenge, but we're not down nor are we out.
>
>Deadline is November 1st, as explained at length, here:
>https://www.ietf.org/mail-archive/web/dnsop/current/msg14065.html
>
>
>> (I'm hoping to write something on the EFF site about this issue,
>which
>> may have kind of far-reaching consequences.)
>
>
>Good.  Please avoid repeating the doom-and-gloom stuff that I've seen
>elsewhere, it distracts from the discussion to have to expend time
>correcting folk on Twitter.
>
>
>> Anyway, I would encourage anyone who wants to work on this issue to
>get
>> in touch with Christian Grothoff, the lead author of the P2P Names
>draft,
>> and ask what the status is and how to help out.
>
>
>The P2P Names draft is not relevant for ".onion" registration; for
>other Tor-related names such as ".exit", and other services such as
>".i2p" it is still relevant.
>
>
>> Theoretically the Tor Browser could come up with a different optional
>> mechanism for ensuring the integrity of TLS connections to hidden
>services
>> (based on the idea that virtually everyone who tries to use the
>hidden
>> services is using the Tor Browser code).  I don't know whether the
>Tor
>> Browser developers currently think this is a worthwhile path. I can
>> think of arguments against it -- in particular, the next generation
>hidden
>> services design will provide much better cryptographic security than
>the
>> current HS mechanism does, so maybe it should just be a higher
>priority
>> to get that rolled out, rather than trying to make up new mechanisms
>to
>> help people use TLS on hidden services.
>
>
>I would recommend against giving up the pursuit of HTTPS certificates
>on Onion sites.
>
>I explained some of this at
>https://lists.torproject.org/pipermail/tor-talk/2015-August/038712.html
>as follows:
>
>
>Alec wrote:
>>> The reason [ for pursuing SSL ] is simply that HTTP and HTTPS have
>diverged (and are apparently likely to diverge further?) in how they
>treat (eg:) secure cookies, and rolling a custom version of our
>codebase to know and understand that âHTTP over Onionâ
>will/may/will-not have features like referrer-scrubbing or CORS in a
>HTTPS-sympathetic manner (whilst the scheme in the request still *says*
>that it arrived over HTTP) would be complex. I personally feel that to
>expect more common codebases such as Wordpress or Drupal to
>special-case Onion addresses would be presumptuous, be unlikely, add
>cost, and inhibit Onion adoption.
>
>
>Not creating barriers to wider onion adoption seems like a good idea to
>me.
>
>Giving TorBrowserBundle special powers to make secure connections to
>Onion sites, thereby making (say) "stunnel" or "wget" ineffective for
>OnionSites, seems also to be a bad idea for adoption.
>
>Conversely: Mozilla are going to start gating some of their features to
>be SSL-only:
>https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
>
>Thus: making SSL work *somehow* - with privacy preservation where
>relevant - on onion sites, appears to be the path to greatest onion
>adoption.
>
>
>> elrippo writes:
>> 
>>> Hy,
>>> i don't think letsencrypt will work on a HS because letsencrypt
>checks [1] if the domain you type in, is registered.
>>> So for example on a clearnet IP which has a registered domain at
>mydomain.com called myserver.tld, letsencrypt
>>> makes a DNS check for this clearnet IP and gets the awnser, that
>this clearnet IP has a registeres domain called
>>> myserver.tld on mydomain.com.
>>> 
>>> How should letsencrypt do this on a HS?
>> 
>> If the CA/Browser Forum agreed that it was proper to do this, we
>could
>> create a special case for requests that include a .onion name to use
>> a different (non-DNS) resolution mechanism, recognizing "that DNS is
>> not the only name resolution protocol on the Internet", as Christian
>> Grothoff put it.
>
>
>...etc.
>
>For organisations which can arrange to register a EV certificate -
>companies, etc - once the ".onion" domain is formalised it will be
>possible to get a EV certificate created for an Onion address by using
>the process documented at
>https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/
>
>Seth is precisely correct, however, that there is no means (yet) for
>individuals to register .Onion addresses for certificates, let alone
>anonymously.
>
>I had discussions with some people in CA/B-Forum a few weeks ago, and
>there may be a way to pursue these ("IV Certificates" - see
>https://wiki.mozilla.org/CA:Glossary for details) - and assuming the
>.onion registration completes smoothly, I think that would be a good
>path to pursue.
>
>
>> In a way, the special-casing is what makes some folks in the
>CA/Browser
>> Forum nervous right now: if there's no "official" notion of the
>meaning
>> of some names, how can CAs know which names should use which
>resolution
>> mechanisms?  (For example, maybe some CAs have heard that they should
>> treat .onion specially, but others haven't.)  If they're unsure which
>> mechanisms to use, how can they know that the interpretation they
>give
>> to the names will be the same as end-users
>
>
>Very true, it's complicated.
>
>Fortunately the light at the end of the tunnel, for once, is not an
>oncoming train.
>
>    - alec
>
>
>--
>Alec Muffett
>Security Infrastructure
>Facebook Engineering
>London
>
>
>
>------------------------------------------------------------------------
>
>-- 
>tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
>To unsubscribe or change other settings go to
>https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk