[tor-commits] [stem/master] Better normalize ORPort SSL connection failures

atagar at torproject.org atagar at torproject.org
Fri Oct 5 17:32:15 UTC 2018


commit 0f0ba5d53468223ea8ca42887f103af16fc37291
Author: Damian Johnson <atagar at torproject.org>
Date:   Thu Oct 4 11:10:01 2018 -0700

    Better normalize ORPort SSL connection failures
    
    On reflection the assertion failure addressed in commit 0e08db7 was a
    legitimate one. It was exposing a bug in our error response normalization.
    Reverting the change to the test and doing a proper fix.
---
 stem/client/__init__.py         | 14 +++++++++++---
 test/integ/client/connection.py | 16 +---------------
 2 files changed, 12 insertions(+), 18 deletions(-)

diff --git a/stem/client/__init__.py b/stem/client/__init__.py
index aaa62f5b..6cadc098 100644
--- a/stem/client/__init__.py
+++ b/stem/client/__init__.py
@@ -82,10 +82,18 @@ class Relay(object):
     except stem.SocketError as exc:
       if 'Connection refused' in str(exc):
         raise stem.SocketError("Failed to connect to %s:%i. Maybe it isn't an ORPort?" % (address, port))
-      elif 'SSL: ' in str(exc):
+
+      # If not an ORPort (for instance, mistakenly connecting to a ControlPort
+      # instead) we'll likely fail during SSL negotiation. This can result
+      # in a variety of responses so normalizing what we can...
+      #
+      #   Ubuntu 16.04:   [SSL: UNKNOWN_PROTOCOL] unknown protocol (_ssl.c:590)
+      #   Ubuntu 12.04:   [Errno 1] _ssl.c:504: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
+
+      if 'unknown protocol' in str(exc):
         raise stem.SocketError("Failed to SSL authenticate to %s:%i. Maybe it isn't an ORPort?" % (address, port))
-      else:
-        raise
+
+      raise
 
     # To negotiate our link protocol the first VERSIONS cell is expected to use
     # a circuit ID field size from protocol version 1-3 for backward
diff --git a/test/integ/client/connection.py b/test/integ/client/connection.py
index ca8853c7..a43283b9 100644
--- a/test/integ/client/connection.py
+++ b/test/integ/client/connection.py
@@ -31,21 +31,7 @@ class TestConnection(unittest.TestCase):
     # connect to our ControlPort like it's an ORPort
 
     if test.runner.Torrc.PORT in test.runner.get_runner().get_options():
-      try:
-        Relay.connect('127.0.0.1', test.runner.CONTROL_PORT)
-        self.fail('Connecting to a non-ORPort should raise a stem.SocketError')
-      except stem.SocketError as exc:
-        if str(exc) == "Failed to SSL authenticate to 127.0.0.1:1111. Maybe it isn't an ORPort?":
-          pass  # good, this is the usual response
-        elif 'SSL23_GET_SERVER_HELLO:unknown protocol' in str(exc):
-          # Less common, but still ok. This arises on older systems that do not
-          # support tor's ssl version. The full response is...
-          #
-          #   [Errno 1] _ssl.c:504: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
-
-          pass
-        else:
-          self.fail('Unexpected response when connecting to a non-ORPort: %s' % exc)
+      self.assertRaisesWith(stem.SocketError, "Failed to SSL authenticate to 127.0.0.1:1111. Maybe it isn't an ORPort?", Relay.connect, '127.0.0.1', test.runner.CONTROL_PORT)
 
   def test_no_common_link_protocol(self):
     """





More information about the tor-commits mailing list