Skip to content
This repository has been archived by the owner on Aug 20, 2022. It is now read-only.

SoftLayer servers fail TLS 1.1 negotiation #17

Closed
benmccann opened this issue Apr 2, 2013 · 11 comments
Closed

SoftLayer servers fail TLS 1.1 negotiation #17

benmccann opened this issue Apr 2, 2013 · 11 comments

Comments

@benmccann
Copy link
Contributor

Using this client library results in the following error on Ubuntu 12.04:
SSLError: [Errno 8] _ssl.c:504: EOF occurred in violation of protocol

The bug needs to be fixed on SoftLayer's servers. See https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/965371

@CrackerJackMack
Copy link
Contributor

EDIT: I'm a derp, just read which package this is for. It's for object storage, not the API bindings. Will respond in a second.

Yipes! Ok cool, thanks for the heads up.

Not denying that it exist, just trying to reproduce it so we know when it's fixed. I have a 12.04 server and using openssl s_client -connect api.softlayer.com:443 works fine. I read a lot of the bug report and that seems to be how they were testing it. If you have another method or a gist I can test with I would appreciate it. I tried both version of SSL (upgraded and non-upgraded) and got the same results.

 lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 12.04.2 LTS
Release:        12.04
Codename:       precise
$ aptitude show openssl
Package: openssl
State: installed
Automatically installed: no
Version: 1.0.1-4ubuntu5.7
Priority: standard
Section: utils
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architecture: amd64
Uncompressed Size: 923 k
Depends: libc6 (>= 2.15), libssl1.0.0 (>= 1.0.1)
Suggests: ca-certificates
Conflicts: openssl
Description: Secure Socket Layer (SSL) binary and related cryptographic tools
 This package contains the openssl binary and related tools.
$ apt-cache policy openssl
openssl:
  Installed: 1.0.1-4ubuntu5.7
  Candidate: 1.0.1-4ubuntu5.8
  Version table:
     1.0.1-4ubuntu5.8 0
        500 http://mirrors.service.networklayer.com/ubuntu/ precise-updates/main amd64 Packages
        500 http://mirrors.service.networklayer.com/ubuntu/ precise-security/main amd64 Packages
 *** 1.0.1-4ubuntu5.7 0
        100 /var/lib/dpkg/status
     1.0.1-4ubuntu3 0
        500 http://mirrors.service.networklayer.com/ubuntu/ precise/main amd64 Packages

@CrackerJackMack
Copy link
Contributor

Hrm, wasn't able to reproduce it using that command either. I'll have to test with the bindings a tad later. I'd like to nail down a reproducible test so we can verify changing the SSL settings have indeed fixed the solution.

$ openssl s_client -connect dal05.objectstorage.softlayer.net:443
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
....... [ SNIP ] ................
---
No client certificate CA names sent
---
SSL handshake has read 3509 bytes and written 552 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 4FD9F9DE410FA3CAC8CAA64230783D3872070BA0932F837BAA53170CAB84154C
    Session-ID-ctx:
    Master-Key: 581B62DEA9DE6C2E980B7F99680B18C4ECA8401638664BD368A314A41AF8B1F56B400B3C5083E21B645A731C2CB106E8
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
    0000 - 77 8e ff 87 4f 1c 63 19-54 3c 8f 77 a7 64 58 8a   w...O.c.T<.w.dX.
    0010 - 06 32 c4 29 aa f0 fd a6-16 69 4b 5c dc 21 93 ce   .2.).....iK\.!..
    0020 - 14 1a 41 80 e3 dd dd a6-e8 d4 d2 2c e0 a9 a4 88   ..A........,....
    0030 - c9 84 6e 06 cd e8 81 7e-09 b8 18 41 64 05 a7 cf   ..n....~...Ad...
    0040 - 64 40 aa 89 58 1d a8 b5-14 cc a5 d8 af 5d d8 de   d@..X........]..
    0050 - e3 f7 f2 57 b1 c6 21 7a-6b 56 35 3c 34 a7 6d 0c   ...W..!zkV5<4.m.
    0060 - 69 01 b4 75 61 ff 64 06-b0 6d 5e 92 2f a9 8f c0   i..ua.d..m^./...
    0070 - 92 3e 6b 4d 54 56 23 0d-ad 0a 3b 63 fb 7c 2b 01   .>kMTV#...;c.|+.
    0080 - 09 65 68 ee 08 72 d7 cb-ef 07 ca 33 b1 24 b1 22   .eh..r.....3.$."
    0090 - 0a b9 16 45 0c 9c 5d b0-2f 62 44 ff b4 ac 67 25   ...E..]./bD...g%
    00a0 - 43 d1 72 15 a1 27 9d 33-a7 18 5e 32 51 ec 53 6a   C.r..'.3..^2Q.Sj

    Compression: 1 (zlib compression)
    Start Time: 1364877181
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)

@benmccann
Copy link
Contributor Author

This should work for reproducing:

sudo pip install softlayer-object-storage
git clone git@github.com:benmccann/object-storage-load-test.git
git reset --hard c2ba3e0fd7245b3b558614e8b256e2a10f31b0f6
./runtest.py --username xxxxx --password xxxxx

@CrackerJackMack
Copy link
Contributor

Thanks. Will investigate on our side of things.

@benmccann
Copy link
Contributor Author

Were you able to reproduce?

@CrackerJackMack
Copy link
Contributor

I deployed a new 12.04 CCI, replicated the above commands and I was not able to reproduce. Does the error happen instantly or eventually?

@CrackerJackMack
Copy link
Contributor

Ah, it's eventual. Checking some more

@CrackerJackMack
Copy link
Contributor

I was able to eventually reproduce the issue using the scripts you provided. However looking at the script, it was exhibiting some really bad behavior anyway, so I patched that up and was not able to reproduce the issue even with 300 threads and 2000 uploads. Please review my changes and tell my if I am off the path?

diff --git a/runtest.py b/runtest.py
index 80f8e8c..9db0c37 100755
--- a/runtest.py
+++ b/runtest.py
@@ -6,6 +6,7 @@ import random
 import string
 import time
 import traceback
+from itertools import repeat
 from multiprocessing import Pool

 parser = argparse.ArgumentParser(description='Load test object storage')
@@ -13,6 +14,11 @@ parser.add_argument('--username', type=str, dest='username', required=True,
                    help='object storage username')
 parser.add_argument('--password', type=str, dest='password', required=True,
                    help='object storage password')
+
+parser.add_argument('--threads', '-t', type=int, dest='threads', required=False,
+                   help='threads to spawn', default=100)
+parser.add_argument('--count', '-c', type=int, dest='limit', required=False,
+                   help='total objects to upload', default=2000)
 args = parser.parse_args()

 def upload(data):
@@ -26,13 +32,18 @@ def upload(data):
     print 'Received ' + e.status + ': ' + e.reason
   except:
     print traceback.format_exc()
-  time.sleep(1)
-  upload(data)
+  else:
+    time.sleep(1)

 with open ('test.html', 'r') as myfile:
   data = myfile.read()
-  pool = Pool(processes=10)
-  for i in range(20):
-    pool.apply_async(upload, args=(data,))
-  pool.close()
-  pool.join()
+  pool = Pool(processes=args.threads)
+  async_res = pool.map_async(upload, repeat(data, args.limit))
+  while not async_res.wait(5):
+    if async_res.ready():
+       print("results are ready")
+       break
+    else:
+       print("Waiting for results") 
+
+  pool.terminate()

@benmccann
Copy link
Contributor Author

Hmm, that's strange. I thought it was happening with a single request previously, but I can't reproduce that now.

Thanks for looking at my load test code. The real problem we're having is from our servers accessing object storage in Java, which I think are better behaved, but still overwhelm object store. Object store cannot take enough load from us. We aren't actually being blocked as a DOS attack are we? What's the limit to the number of requests per send that we can make? I'm surprised that one laptop could overwhelm the object storage no matter how fast it's making requests.

@freemanchari
Copy link

Just for future reference, this problem is caused by having client that uses openssl that supports TLSv1.1 or 1.2 trying to connect to a server that only supports TLSv1. CrackerJackMax could not reproduce because his client supported TLSv1 too so the handshake went through

@briancline
Copy link
Member

As of October, we currently support TLSv1.2, v1.1, and v1.0, so excessive TLS renegotiation shouldn't be occurring anymore. If so, please open a new issue if this still occurs. Thanks!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants