[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] obfsproxy failure: obfs3
I'm still having trouble connecting to my obfsproxy bridge; Any pointers
would be appreciated. External scanning indicates that the correct ports
are open except for port 443 but it's definitely open on the firewall.
lee@li388-156:~$ nmap -p 22,443,9001,40872,52176 173.255.119.202
Starting Nmap 5.21 ( http://nmap.org ) at 2013-08-21 16:44 EDT
Nmap scan report for 202.119.255.173.bc.googleusercontent.com (173.255.119.202)
Host is up (0.16s latency).
PORT STATE SERVICE
22/tcp open ssh
443/tcp closed https
9001/tcp open tor-orport
40872/tcp open unknown
52176/tcp open unknown
lee@li388-156:~$ openssl s_client -showcerts -connect 173.255.119.202:443
connect: Connection refused
connect:errno=111
maybe this? https://trac.torproject.org/projects/tor/ticket/5104
Confirming that 443 is accessible:
lee@tor-bootstrap:~$ sudo python -m SimpleHTTPServer 443
Serving HTTP on 0.0.0.0 port 443 ...
106.187.45.156 - - [21/Aug/2013 22:39:16] code 400, message Bad
request syntax ('\x16\x03\x01\x00\xdc\x01\x00\x00\xd8\x03\x02R\x15A\x94\xc5\xfc\xc1(\x04O\xe0\xee@\x92d\x17.\xd9N\xa1Q\xb3$_\xa6H\xc6adp\xa11\x00\x00f\xc0\x14\xc0')
106.187.45.156 - - [21/Aug/2013 22:39:16]
"ïïRAïïïï(Oïï@ïd.ïNïQï$_ïHïadpï1fïï" 400 -
lee@li388-156:~$ openssl s_client -showcerts -connect 173.255.119.202:443
CONNECTED(00000003)
140181545842336:error:140770FC:SSL
routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:749:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 225 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
On Thu, Aug 15, 2013 at 10:14 AM, lee colleton <lee@xxxxxxxxxxxx> wrote:
> -tor-relay
> +tor-relays
>
>
> On Thu, Aug 15, 2013 at 10:13 AM, lee colleton <lee@xxxxxxxxxxxx> wrote:
>
>> All of the ports respond on the external IP except for 443 but I can
>> connect via SSL on 9001. I don't understand how ORListenAddress is
>> supposed to work: my bridge times out on 443 but when I comment out the ORListenAddress
>> line it doesn't connect via obfsproxy at all.
>>
>> Please advise.
>>
>>
>> On Thu, Aug 15, 2013 at 1:47 AM, lee colleton <lee@xxxxxxxxxxxx> wrote:
>>
>>> With the ORListenAddress line uncommented, a slightly different failure
>>> results:
>>>
>>> Orbot is startingâ
>>> Orbot is startingâ
>>> got tor proc id: 28490
>>> Tor process id=28490
>>>
>>> Connecting to control port: 9051
>>> SUCCESS connected to control port
>>> SUCCESS authenticated to control port
>>> Starting Tor clientâ complete.
>>> adding control port event handler
>>> SUCCESS added control port event handler
>>> Starting privoxy process
>>> /data/data/org.torproject.android/app_bin/privoxy
>>> /data/data/org.torproject.android/app_bin/privoxy.config &
>>> NOTICE: Heartbeat: Tor's uptime is 0:00 hours, with 0 circuits open.
>>> I've sent 0 kB and received 0 kB.
>>> Privoxy is running on port:8118
>>> Privoxy process id=28508
>>>
>>> Network connectivity is good. Waking Tor up...
>>> Circuit (1) LAUNCHED:
>>> NOTICE: Bootstrapped 5%: Connecting to directory server.
>>> orConnStatus (173.255.119.202:443): LAUNCHED
>>> NOTICE: Bootstrapped 10%: Finishing handshake with directory server.
>>> Circuit (1) FAILED: ONEHOP_TUNNEL > IS_INTERNAL > NEED_CAPACITY
>>> NOTICE: Your application (using socks4a to port 443) instructed Tor to
>>> take care of the DNS resolution itself if necessary. This is good.
>>> NOTICE: Your application (using socks4a to port 80) instructed Tor to
>>> take care of the DNS resolution itself if necessary. This is good.
>>> NOTICE: Your application (using socks4a to port 443) instructed Tor to
>>> take care of the DNS resolution itself if necessary. This is good.
>>> NOTICE: Your application (using socks4a to port 80) instructed Tor to
>>> take care of the DNS resolution itself if necessary. This is good.
>>> NOTICE: Your application (using socks4a to port 443) instructed Tor to
>>> take care of the DNS resolution itself if necessary. This is good.
>>> NOTICE: Your application (using socks4a to port 80) instructed Tor to
>>> take care of the DNS resolution itself if necessary. This is good.
>>> NOTICE: Your application (using socks4a to port 443) instructed Tor to
>>> take care of the DNS resolution itself if necessary. This is good.
>>> NOTICE: Tried for 120 seconds to get a connection to [scrubbed]:443.
>>> Giving up. (waiting for circuit)
>>> NOTICE: Your application (using socks4a to port 443) instructed Tor to
>>> take care of the DNS resolution itself if necessary. This is good.
>>>
>>> On Aug 15, 2013 1:41 AM, "lee colleton" <lee@xxxxxxxxxxxx> wrote:
>>>
>>>> When I attempt to connect to this bridge, I see a failure in
>>>> handshaking:
>>>>
>>>> Orbot is startingâ
>>>> Orbot is startingâ
>>>> got tor proc id: 27365
>>>> Tor process id=27365
>>>> Connecting to control port: 9051
>>>> SUCCESS connected to control port
>>>> SUCCESS authenticated to control port
>>>> Starting Tor clientâ complete.
>>>> adding control port event handler
>>>> SUCCESS added control port event handler
>>>> Starting privoxy process
>>>> /data/data/org.torproject.android/app_bin/privoxy
>>>> /data/data/org.torproject.android/app_bin/privoxy.config &
>>>> NOTICE: Heartbeat: Tor's uptime is 0:00 hours, with 0 circuits open.
>>>> I've sent 0 kB and received 0 kB.
>>>> Privoxy is running on port:8118
>>>> Privoxy process id=27393
>>>> Network connectivity is good. Waking Tor up...
>>>> Circuit (1) LAUNCHED:
>>>> NOTICE: Bootstrapped 5%: Connecting to directory server.
>>>> orConnStatus (173.255.119.202:443): LAUNCHED
>>>> NOTICE: Bootstrapped 10%: Finishing handshake with directory server.
>>>> NOTICE: We weren't able to find support for all of the TLS ciphersuites
>>>> that we wanted to advertise. This won't hurt security, but it might make
>>>> your Tor (if run as a client) more easy for censors to block.
>>>> NOTICE: To correct this, use a more recent OpenSSL, built without
>>>> disabling any secure ciphers or features.
>>>> Circuit (1) FAILED: ONEHOP_TUNNEL > IS_INTERNAL > NEED_CAPACITY
>>>> orConnStatus (173.255.119.202:443): FAILED
>>>> WARN: Problem bootstrapping. Stuck at 10%: Finishing handshake with
>>>> directory server. (DONE; DONE; count 1; recommendation warn)
>>>> WARN: 1 connections have failed:
>>>> WARN: 1 connections died in state handshaking (TLS) with SSL state
>>>> SSLv2/v3 read server hello A in HANDSHAKE
>>>> NOTICE: Your application (using socks4a to port 80) instructed Tor to
>>>> take care of the DNS resolution itself if necessary. This is good.
>>>> NOTICE: Your application (using socks4a to port 443) instructed Tor to
>>>> take care of the DNS resolution itself if necessary. This is good.
>>>> NOTICE: Your application (using socks4a to port 80) instructed Tor to
>>>> take care of the DNS resolution itself if necessary. This is good.
>>>> On Aug 15, 2013 12:31 AM, "lee colleton" <lee@xxxxxxxxxxxx> wrote:
>>>>
>>>>> When I comment out the ORListenAddress line things look OK.
>>>>>
>>>>> # Listen on a port other than the one advertised in ORPort (that is,
>>>>> # advertise 443 but bind to 9001).
>>>>> #ORListenAddress 0.0.0.0:9001
>>>>>
>>>>> Aug 15 06:52:50.000 [notice] Tor 0.2.4.16-rc (git-dcf6b6d7dda9ffbd) opening log file.
>>>>> Aug 15 06:52:50.000 [notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster.
>>>>> Aug 15 06:52:50.000 [notice] Your Tor server's identity key fingerprint is 'gcedemo 08C752E8E86EB5916574A8625030B0EC204EABB8'
>>>>> Aug 15 06:52:50.000 [notice] Configured hibernation. This interval began at 2013-08-15 00:00:00; the scheduled wake-up time was 2013-08-15 00:00:00; we expect to exhaust our quota for this interval around 2013-08-16 00:00:00; the next interval begins at 2013-08-16 00:00:00 (all times local)
>>>>> Aug 15 06:52:50.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
>>>>> Aug 15 06:52:50.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
>>>>> Aug 15 06:52:50.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
>>>>> Aug 15 06:52:51.000 [notice] We now have enough directory information to build circuits.
>>>>> Aug 15 06:52:51.000 [notice] Bootstrapped 80%: Connecting to the Tor network.
>>>>> Aug 15 06:52:52.000 [notice] Bootstrapped 85%: Finishing handshake with first hop.
>>>>> Aug 15 06:52:53.000 [notice] Guessed our IP address as 173.255.119.202 (source: 38.229.70.33).
>>>>> Aug 15 06:52:53.000 [notice] Bootstrapped 90%: Establishing a Tor circuit.
>>>>> Aug 15 06:52:53.000 [notice] Registered server transport 'obfs3' at '0.0.0.0:40872'
>>>>> Aug 15 06:52:53.000 [notice] Registered server transport 'obfs2' at '0.0.0.0:52176'
>>>>> Aug 15 06:52:55.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
>>>>> Aug 15 06:52:55.000 [notice] Bootstrapped 100%: Done.
>>>>> Aug 15 06:52:55.000 [notice] Now checking whether ORPort 173.255.119.202:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
>>>>> Aug 15 06:53:04.000 [notice] New control connection opened.
>>>>> Aug 15 07:10:11.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 14, 2013 at 9:53 PM, lee colleton <lee@xxxxxxxxxxxx>wrote:
>>>>>
>>>>>> Yes, I've opened the ports in the Google Compute Engine (see below).
>>>>>> I'll follow up on their forum to make sure I've altered the firewall
>>>>>> properly.
>>>>>>
>>>>>> --lee
>>>>>>
>>>>>> lee@li388-156:~$ gcutil --service_version="v1beta15" --project="colleton.net:tor-cloud" listfirewalls
>>>>>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+
>>>>>> | name | description | network | source-ips | source-tags | target-tags |
>>>>>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+
>>>>>> | default-allow-internal | Internal traffic from default allowed | default | 10.0.0.0/8 | | |
>>>>>> | default-ssh | SSH allowed from anywhere | default | 0.0.0.0/0 | | |
>>>>>> | tor-obfsproxy | | default | 0.0.0.0/0 | | obfsproxy |
>>>>>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+
>>>>>> lee@li388-156:~$ gcutil --service_version="v1beta15" --project="colleton.net:tor-cloud" getfirewall tor-obfsproxy
>>>>>> +---------------+-------------------------------+
>>>>>> | property | value |
>>>>>> +---------------+-------------------------------+
>>>>>> | name | tor-obfsproxy |
>>>>>> | description | |
>>>>>> | creation-time | 2013-08-07T18:37:35.986-07:00 |
>>>>>> | network | default |
>>>>>> | source-ips | 0.0.0.0/0 |
>>>>>> | source-tags | |
>>>>>> | target-tags | obfsproxy |
>>>>>> | allowed | tcp: 443, 9001, 40872, 52176 |
>>>>>> +---------------+-------------------------------+
>>>>>> lee@li388-156:~$
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Aug 14, 2013 at 9:19 PM, Roger Dingledine <arma@xxxxxxx>wrote:
>>>>>>
>>>>>>> On Wed, Aug 14, 2013 at 09:08:03AM -0700, lee colleton wrote:
>>>>>>> > There's a more serious issue in that my server doesn't appear to be
>>>>>>> > reachable. I've opened tcp:443,9001 along with the two
>>>>>>> specifiedobfsproxy
>>>>>>> > ports
>>>>>>> >
>>>>>>> > Aug 14 15:26:58.000 [notice] Bootstrapped 100%: Done.
>>>>>>> > Aug 14 15:26:58.000 [notice] Now checking whether ORPort
>>>>>>> > 173.255.119.202:443 is reachable... (this may take up to 20
>>>>>>> minutes --
>>>>>>> > look for log messages indicating success)
>>>>>>> > Aug 14 15:28:00.000 [notice] New control connection opened.
>>>>>>> > Aug 14 15:46:56.000 [warn] Your server (173.255.119.202:443) has
>>>>>>> not
>>>>>>> > managed to confirm that its ORPort is reachable. Please check your
>>>>>>> > firewalls, ports, address, /etc/hosts file, etc.
>>>>>>>
>>>>>>> Well, that's because it's unreachable. (I just tried.)
>>>>>>>
>>>>>>> Can you try following the suggestion in the log message?
>>>>>>>
>>>>>>> --Roger
>>>>>>>
>>>>>>> --
>>>>>>> tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
>>>>>>> To unsusbscribe or change other settings go to
>>>>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>
>
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsusbscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk