SSL error after update to 3.11.15

sailor · September 25, 2019, 9:09am

Dears,

We’re running globaleaks on an headless Ubuntu server 18.04.3 LTS (GNU/Linux 4.15.0-64-generic x86_64).
After an update to 3.11.15, we get errors in the browsers, i.e.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH in chrome and
SSL_ERROR_NO_CYPHER_OVERLAP in firefox

Other servers (tried eg with webmin) work and remain accessable.
Tried --reinstall, but for no good.

Anyone having a hint where to look at?

evilaliv3 · September 25, 2019, 9:17am

Dear @sailor,

thank you for your contact.

Actually the solution is easy and already experimented with an other user (Globaleaks error after upgrade to 3.11.12) but would like to ask you if you could help me collecting feedback in order to solve the issue in the software packaging.

To solve you just need run: apt-get update && apt-get upgrade and then restart globaleaks with /etc/init.d/globaleaks restart

I would kindly ask you to provide the output of the commands apt-get upgrade in order to understand which is the library for which you are missing an update.

thank you so much,

all the best,

Giovanni Pellerano

sailor · September 25, 2019, 9:25am

Dear Giovanni,

that’s actually what we had done already, it appears everything is up-to-date:

apt upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

There’s nothing to update (anymore). We restartet not only the service, but also the server itself.
However, just tried again, ststua output shows as follows:

service globaleaks status
● globaleaks.service - LSB: Start the GlobaLeaks server.
   Loaded: loaded (/etc/init.d/globaleaks; generated)
   Active: active (running) since Wed 2019-09-25 11:21:46 CEST; 5s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 7687 ExecStop=/etc/init.d/globaleaks stop (code=exited, status=0/SUCCESS)
  Process: 7714 ExecStart=/etc/init.d/globaleaks start (code=exited, status=0/SUCCESS)
    Tasks: 5 (limit: 2340)
   CGroup: /system.slice/globaleaks.service
           └─7760 /usr/bin/python3 /usr/bin/globaleaks --ip=0.0.0.0 --user=globaleaks --group=globaleaks --working-path=/var/globaleaks/

Sep 25 11:21:44 globaleaks systemd[1]: Starting LSB: Start the GlobaLeaks server....
Sep 25 11:21:45 globaleaks globaleaks[7714]:  * Starting GlobaLeaks daemon globaleaks
Sep 25 11:21:46 globaleaks globaleaks[7714]:    ...done.
Sep 25 11:21:46 globaleaks systemd[1]: Started LSB: Start the GlobaLeaks server..

Log file shows:

2019-09-25 11:21:43+0200 [-] Server Shut Down. 2019-09-25 11:21:43+0200 [-] Exiting GlobaLeaks 2019-09-25 11:21:46+0200 [-] twistd 17.9.0 (/usr/bin/python3 3.6.8) starting up. 2019-09-25 11:21:46+0200 [-] reactor class: twisted.internet.epollreactor.EPollReactor. 2019-09-25 11:21:46+0200 [-] /usr/lib/python3/dist-packages/sqlalchemy/ext/declarative/clsregistry.py:120: sqlalchemy.exc.SAWarning: This declarative base already contains a class with the same class name and module name as globaleaks.db.migration.y, and will be replaced in the string-lookup table. 2019-09-25 11:21:50+0200 [-] [E] Found an already initialized database version: 51 2019-09-25 11:21:51+0200 [-] Starting factory <Site object at 0x7f2f0fb889e8> 2019-09-25 11:21:51+0200 [-] GlobaLeaks is now running and accessible at the following urls: 2019-09-25 11:21:51+0200 [-] - [HTTP] --> http://0.0.0.0 2019-09-25 11:21:51+0200 [-] - [Tor]: --> xxxxsecretxxx.onion 2019-09-25 11:21:51+0200 [-] [E] Successfully connected to Tor control port

evilaliv3 · September 25, 2019, 9:27am

Thank you for your feedback,

would you please provide the HTTPS link so to be able to check it from our side?

sailor · September 25, 2019, 9:30am

It’s internal only and behind a firewall, since we run it only for organizational compliance.

Let me know what info you are after, I can try to post it

evilaliv3 · September 25, 2019, 9:38am

I see.

Are you able to reach it locally via HTTPS via curl or wget?

I suspect that if you have implemented an HTTPS proxy the reason of the failure could be that globaleks requires a proxy secure cyphers that the proxy still does not satisy. If this is the case would you please check this?

sailor · September 25, 2019, 9:51am

via curl

curl https://localhost:443
curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

evilaliv3 · September 25, 2019, 9:58am

Would you please share the output of curl with the option “-vvv”?

sailor · September 25, 2019, 9:59am

curl -vvv https://localhost:443
* Rebuilt URL to: https://localhost:443/
*   Trying ::1...
* TCP_NODELAY set
* connect to ::1 port 443 failed: Verbindungsaufbau abgelehnt
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, Server hello (2):
* error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
* Closing connection 0
curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

evilaliv3 · September 25, 2019, 10:05am

To dig in with more detail would you please share the output of: openssl s_client -connect https://localhost:443 ?

sailor · September 25, 2019, 10:08am

This would give me an error for malformed command.
s_client: -connect argument or target parameter malformed or ambiguous

I tried this instead:

openssl s_client -connect https://127.0.0.1 -port 443`
139792868073920:error:2008F002:BIO routines:BIO_lookup_ex:system lib:../crypto/bio/b_addr.c:704:Servname not supported for ai_socktype
connect:errno=0

sailor · September 25, 2019, 10:17am

This seemed to work better:

openssl s_client -connect 127.0.0.1 -port 443
CONNECTED(00000005)
140534311408064:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1528:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 311 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

evilaliv3 · September 25, 2019, 10:32am

Thank you, we are doing some retesting and i will get back to you as soon we have identified the issue/remediation.

In general for reporting bugs like this please use our ticketing system: https://github.com/globaleaks/GlobaLeaks/issues

evilaliv3 · September 25, 2019, 10:34am

In the meantime would you please check if /var/globaleaks/log/globaleaks.log contains any debugging detail in relation to this failure?

sailor · September 25, 2019, 10:36am

The log file doesn’t show any entries when trying to connect (neither via browser, nor via openssl test).
Thus I would dare to say: no log entries related. sorry.

evilaliv3 · September 25, 2019, 12:34pm

@sailor: I think may have identified the reason of the failure.

Would you please answer the following questions?

is this a multitenant setup?
if yes do you have HTTPS on the root tenant?

sailor · September 25, 2019, 12:53pm

No, it’s not multitenant.

The whole globaleaks package is installed on a dedicated (although in a KVM virtual) machine.

evilaliv3 · September 25, 2019, 12:56pm

I think actually that the issue could be that you are accessing via the IP.

How is the certificate issued? is it a self signed?

fpietrosanti · September 25, 2019, 12:57pm

Could you try to get the OpenSSL version typing:
dpkg -l | grep -i openssl

and

openssl version

fpietrosanti · September 25, 2019, 12:57pm

Could you try to get the OpenSSL version typing:
dpkg -l | grep -i openssl

and

openssl version