Re: [tor-bugs] #12208 [Obfuscation/meek]: Make it possible to use an IP address as a front (no DNS request and no SNI)

[Tor Bug Tracker & Wiki]

#12208: Make it possible to use an IP address as a front (no DNS request and no
SNI)
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * status:  needs_review => assigned


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12208 [Obfuscation/meek]: Make it possible to use an IP address as a front (no DNS request and no SNI)

[Tor Bug Tracker & Wiki]

#12208: Make it possible to use an IP address as a front (no DNS request and no
SNI)
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by dcf):

 Here are the four use cases I want to support. Cases !#1 and !#2 are
 already supported; this ticket is about adding !#3 and !#4. In the table,
 I separated `urlName` into "DNS name" and "connect to".
  * cdn.ex is at IP address 1.2.3.4
* serves a default certificate for CN=cdn.ex in absence of SNI
  * meek.ex is at IP address 5.5.5.5

 ||   ||||= DNS query =||= connect to =||= `hostName` =||=
 `sniName` =||= `verifyName` =||
 ||!#1||  direct|| meek.ex || 5.5.5.5  || meek.ex  ||
 meek.ex || meek.ex||
 ||!#2|| domain fronting|| cdn.ex  || 1.2.3.4  || meek.ex  ||
 cdn.ex  || cdn.ex ||
 ||!#3|| DNS, no SNI|| cdn.ex  || 1.2.3.4  || meek.ex  ||
 ^''none''^  || cdn.ex ||
 ||!#4||  no DNS, no SNI|| ^''none''^  || 1.2.3.4  || meek.ex  ||
 ^''none''^  || cdn.ex ||

 meek-client takes its configuration in two ways: on a per-connection basis
 via [https://gitweb.torproject.org/torspec.git/tree/pt-
 spec.txt?id=86480728d816474a0771a3b3aba5d223a32f0705#n628 PT SOCKS
 arguments], or globally via [https://gitweb.torproject.org/pluggable-
 transports/meek.git/tree/doc/meek-
 client.1.txt?id=7243a0df885dda442750836b397c2c5d1c7f3e8a#n61 command-line
 options]. SOCKS arguments take precedence over command-line options. Here
 is how cases !#1 and !#2 are represented:

 === !#1 direct
  SOCKS args::
   `url=https://meek.ex/`
  command line::
   `-url https://meek.ex/`
 === !#2 domain fronting
  SOCKS args::
   `url=https://meek.ex/ front=cdn.ex`
  command line::
   `-url https://meek.ex/ -front cdn.ex`

 We have to decide how to represent use cases !#3 and !#4.

 Observations:
  * `hostName` is the name of the final destination, always.
* It comes from the `url` argument and I like that design.
  * The only time `sniName`≠`verifyName` is when `sniName`=''none''.
* That is, there's no need to control `sniName` and `verifyName`
 completely independently, only for an option to blank the `sniName`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12208 [Obfuscation/meek]: Make it possible to use an IP address as a front (no DNS request and no SNI)

[Tor Bug Tracker & Wiki]

#12208: Make it possible to use an IP address as a front (no DNS request and no
SNI)
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arlolra):

 * cc: arlolra (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12208 [Obfuscation/meek]: Make it possible to use an IP address as a front (no DNS request and no SNI)

[Tor Bug Tracker & Wiki]

#12208: Make it possible to use an IP address as a front (no DNS request and no
SNI)
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * cc: brade, mcs (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12208 [Obfuscation/meek]: Make it possible to use an IP address as a front (no DNS request and no SNI)

[Tor Bug Tracker & Wiki]

#12208: Make it possible to use an IP address as a front (no DNS request and no
SNI)
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by dcf):

 Replying to [comment:13 cypherpunks]:
 > > Will it be easier for a censor to block the SNI-less domain fronting
 or it's of similar difficulty as the "original" domain fronting
 implementation?
 >
 > Depends censorship level.
 > https://en.wikipedia.org/wiki/Server_Name_Indication#Support

 Ya it depends.
 [https://www.bamsoftware.com/papers/fronting/#sec:introduction Back in
 June 2014] (ctrl+f for "domainless"), about 16% of observed TLS
 connections didn't have SNI. I don't know what it is now.

 But the TLS fingerprint also matters. If the fingerprint looks exactly
 like a specific version of Firefox, except that it lacks SNI, that's
 probably unusual enough to block. It would only happen in normal use when
 someone browses to an IP address, which is unusual except for rare cases
 like https://1.1.1.1/. For this reason I'm thinking of adopting the
 [https://github.com/refraction-networking/utls utls] library which allows
 modifying the TLS fingerprint from ordinary Go code. In any case, using
 the Firefox helper won't be possible when making SNI-less requests,
 because I'm not aware of any way to control behavior like that from a
 browser extension.

 But another issue is potential blocking by the intermediary services.
 Maybe a CDN decides they want to always require SNI and they stop dropping
 SNI-less connections. [https://www.bamsoftware.com/papers/thesis/#p239
 Cloudflare did this in 2015] on all of their edge servers except for a few
 special ones, requiring SNI and enforcing a match between SNI and Host
 header.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12208 [Obfuscation/meek]: Make it possible to use an IP address as a front (no DNS request and no SNI)

[Tor Bug Tracker & Wiki]

#12208: Make it possible to use an IP address as a front (no DNS request and no
SNI)
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 > Will it be easier for a censor to block the SNI-less domain fronting or
 it's of similar difficulty as the "original" domain fronting
 implementation?

 Depends censorship level.

 https://en.wikipedia.org/wiki/Server_Name_Indication#Support

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12208 [Obfuscation/meek]: Make it possible to use an IP address as a front (no DNS request and no SNI)

[Tor Bug Tracker & Wiki]

#12208: Make it possible to use an IP address as a front (no DNS request and no
SNI)
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Will it be easier for a censor to block the SNI-less domain fronting or
 it's of similar difficulty as the "original" domain fronting
 implementation?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12208 [Obfuscation/meek]: Make it possible to use an IP address as a front (no DNS request and no SNI)

[Tor Bug Tracker & Wiki]

#12208: Make it possible to use an IP address as a front (no DNS request and no
SNI)
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * status:  new => needs_review


Comment:

 The past couple of days I've been experimenting with ways to set or omit
 the SNI. There's a demo program in attachment:names.go and I'd appreciate
 any review or questions about design decisions. I took inspiration from
 Ox's [https://gist.github.com/oxtoacart/5e78d25a7f9a9cda10cd
 domainfront.go demo] from 2014, but changes in the standard library
 (especially since Go 1.8) provide better ways to do some things now. If
 this looks good, I'm going to use it as the basis of new code in meek-
 client.

 The basic situation is that we are managing four domain names:
  * `urlName`: this is the name we resolve and actually establish a TCP
 connection with.
  * `hostName`: this is the name that goes in the HTTP Host header.
  * `sniName`: this is the name that goes in the SNI extension.
  * `verifyName`: this is the name that the client verifies the server
 certificate against.
 In normal everyday HTTPS, all four of these names are the same. Domain
 fronting allows `hostName` to differ, but the other three names are the
 same. attachment:names.go shows how to make all four names independent, so
 you can, for example, send no SNI but still verify the server certificate
 against a hostname, while still fronting a different domain in the Host
 header.

 An explanation of some decisions:
  1. The way to set the SNI is to modify `TLSClientConfig.ServerName`; the
 way to set the verification name is to modify the
 `TLSClientConfig.VerifyPeerCertificate` callback. Both of these are
 properties of [https://golang.org/pkg/net/http/#Transport http.Transport],
 which is a long-lived data structure that manages multiple HTTP
 roundtrips. We therefore need a separate `http.Transport` for each unique
 (`sniName`, `verifyName`) pair. The only exception is when `urlName` =
 `sniName` = `verifyName`: that's the built-in behavior of the net/http
 package, so we can share an `http.Transport` in that case. The function
 `getHTTPTransportForNames` creates and caches new `http.Transport`s as
 needed. (And note that `hostName` does not enter this logic at all:
 whether or not you are domain fronting is orthogonal to certificate
 verification.)
  2. The way to omit the SNI extension is to set
 `TLSClientConfig.ServerName` to an IP address. The IP address is not
 actually used for anything else, as long as
 `TLSClientConfig.InsecureSkipVerify` is set. The trick of setting
 `TLSClientConfig.TLSDial`, and then pulling the certificates from the
 `tls.Conn` using `ConnectionState`,
 [https://github.com/golang/go/issues/9126 doesn't work] when a proxy is
 set, because the proxy bypasses the dialer (which is the reason why
 [https://github.com/golang/go/issues/16363 VerifyPeerCertificate was
 introduced]).
  3. We need to use multiple simultaneous `http.Transport`s, so we can't
 just modify the global [https://golang.org/pkg/net/http/#RoundTripper
 http.DefaultTransport] like we do currently. But `http.DefaultTransport`
 has some nice default settings for things like timeouts. Go doesn't
 provide any method for creating a new `http.Transport` that has the
 default settings, and you can't just copy the struct literal because it
 contains mutexes. So I used a reflection trick I found on a mailing list
 to copy just the public struct members. Also if we naively set
 `TLSClientConfig`, it [https://github.com/golang/go/issues/17051 disables
 HTTP/2 support]; because we plan to modify `TLSClientConfig`, we have to
 first call `http2.ConfigureTransport`.

 Here are examples use cases.
  all names equal (ordinary HTTPS)::
  {{{
  $ ./names -host example.com -sni example.com -verify example.com
 https://example.com/
  urlName:"example.com"
  hostName:   "example.com"
  sniName:"example.com"
  verifyName: "example.com"
  HTTP/2.0 200 OK
  }}}
  omit SNI, but still verify::
  {{{
  $ ./names -host example.com -sni "" -verify example.com
 https://example.com/
  urlName:"example.com"
  hostName:   "example.com"
  sniName:""
  verifyName: "example.com"
  HTTP/2.0 200 OK
  }}}
  omit DNS request and SNI, but still verify::
  {{{
  $ dig +short example.com
  93.184.216.34
  $ ./names -host example.com -sni "" -verify example.com
 https://93.184.216.34/
  urlName:"93.184.216.34"
  hostName:   "example.com"
  sniName:""
  verifyName: "example.com"
  HTTP/2.0 200 OK
  }}}
 

Re: [tor-bugs] #12208 [Obfuscation/meek]: Make it possible to use an IP address as a front (no DNS request and no SNI)

[Tor Bug Tracker & Wiki]

#12208: Make it possible to use an IP address as a front (no DNS request and no
SNI)
--+-
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by dcf):

 * Attachment "names.go" added.

 Demo allowing you to set the URL, Host, SNI, and verify names
 independently.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12208 [Obfuscation/meek]: Make it possible to use an IP address as a front (no DNS request and no SNI)

[Tor Bug Tracker & Wiki]

#12208: Make it possible to use an IP address as a front (no DNS request and no
SNI)
--+-
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by dcf):

 Replying to [comment:9 cypherpunks]:
 > > When I tried the same thing in Firefox 29 just now, it simply leaves
 off the server_name extension.
 >
 > Amazon CDN doesn't support for such requests now. Seems like it
 terminates TLS session if ClientHello lack of SNI?

 Thanks for checking this. Could you add a note to
 [[doc/meek#AmazonCloudFront]]?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12208 [Obfuscation/meek]: Make it possible to use an IP address as a front (no DNS request and no SNI)

[Tor Bug Tracker & Wiki]

#12208: Make it possible to use an IP address as a front (no DNS request and no
SNI)
--+-
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by cypherpunks):

 * severity:   => Normal


Comment:

 > When I tried the same thing in Firefox 29 just now, it simply leaves off
 the server_name extension.

 Amazon CDN doesn't support for such requests now. Seems like it terminates
 TLS session if ClientHello lack of SNI?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs