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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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:  normal       |  Milestone:
    Component:  meek         |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+-----------------

Comment (by dcf):

 I didn't find an obvious way to reach this goal.

 In the naked golang HTTPS code (without the browser extension), the first
 thing I tried was putting an IP address in place of www.google.com for the
 --front option.
 {{{
 -ClientTransportPlugin meek exec ./meek-client --url=https://meek-
 reflect.appspot.com/ --front=www.google.com
 +ClientTransportPlugin meek exec ./meek-client --url=https://meek-
 reflect.appspot.com/ --front=74.125.224.116
 }}}
 It works fine up until certificate verification, then exits with this
 error:
 {{{
 error in handling request: x509: cannot validate certificate for
 74.125.224.116 because it doesn't contain any IP SANs
 }}}
 What we would want is to connect to an IP without a domain name, but still
 let the TLS code know that it should use "www.google.com" for verification
 purposes. It doesn't seem possible to do it with the crypto/tls library.
 The
 [https://code.google.com/p/go/source/browse/src/pkg/crypto/tls/handshake_client.go?r=ccf7893cc2f0d9166969b0b2a5c9c3501dca0596#31
 clientHandshake] function
 [https://code.google.com/p/go/source/browse/src/pkg/crypto/tls/handshake_client.go?r=ccf7893cc2f0d9166969b0b2a5c9c3501dca0596#45
 builds a ClientHello] using the value c.config.ServerName, and then later
 [https://code.google.com/p/go/source/browse/src/pkg/crypto/tls/handshake_client.go?r=ccf7893cc2f0d9166969b0b2a5c9c3501dca0596#239
 does verification] using the same value c.config.ServerName. In other
 words, it doesn't look possible to use one value for the SNI and another
 during verification.

 Everything works fine if you set [http://golang.org/pkg/crypto/tls/#Config
 InsecureSkipVerify] on the TLSClientConfig of the Transport, but then of
 course you're not doing any verification.

 The golang HTTPS library, when you connect to an IP address, sends a
 server_name extension whose value is the IP address as a string. When I
 tried the same thing in Firefox 29 just now, it simply leaves off the
 server_name extension.

 How [[GoAgent]] does it is it cooks up its own TLS connection using
 Python's ssl library, Python's ssl library doesn't do any verification,
 and then GoAgent itself does some nonstandard verification, not checking
 any certs but either
 [https://github.com/goagent/goagent/blob/4426c2523815cc0b17651eed9e52ca2a5e59844b/local/proxy.py#L1621
 looking for an organizationName starting with "Google "] or
 [https://github.com/goagent/goagent/blob/4426c2523815cc0b17651eed9e52ca2a5e59844b/local/proxy.py#L1681
 looking for ".google" or ".appspot.com" in the commonName]. It's
 essentially the same as InsecureSkipVerify.

 I don't know yet if there's a way to do what we want in the Firefox and
 Chrome helpers.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12208#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs