SSL error after update to 3.11.15

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?

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

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

Thank you for your feedback,

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

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

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?

via curl

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

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

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

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

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

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)
---

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

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

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.

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

Would you please answer the following questions?

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

No, it’s not multitenant.

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

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?

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

and

openssl version

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

and

openssl version