SSLEOFError: EOF occurred in violation of protocol
qpaz opened this issue · 7 comments
alertrserver instance version is at 0.504 (tls 1.2 on)
e.g. managerClientDatabase ist at 0.501
after i did a apt-get update && apt-get distupgrade the following error occurs on all clients/sensors:
03/14/2019 08:55:12 DEBUG: [client.pyc]: Acquire lock.
03/14/2019 08:55:12 ERROR: [client.pyc]: Connecting to server failed.
Traceback (most recent call last):
File "/opt/alertr/managerClientDatabase/lib/client.py", line 2517, in initializeCommunication
self.client.connect()
File "/opt/alertr/managerClientDatabase/lib/client.py", line 52, in connect
self.sslSocket.connect((self.host, self.port))
File "/usr/lib/python2.7/ssl.py", line 824, in connect
self._real_connect(addr, False)
File "/usr/lib/python2.7/ssl.py", line 815, in _real_connect
self.do_handshake()
File "/usr/lib/python2.7/ssl.py", line 788, in do_handshake
self._sslobj.do_handshake()
SSLEOFError: EOF occurred in violation of protocol (_ssl.c:581)
03/14/2019 08:55:12 DEBUG: [client.pyc]: Release lock.
03/14/2019 08:55:12 CRITICAL: [alertRclient.py]: Connecting to server failed. Try again in 5 seconds.
sounds like there is maybe a cipher problem?
the upgrade installed the following packages on rpi:
Start-Date: 2019-03-11 15:11:15
Commandline: apt-get -y dist-upgrade
Upgrade: libgssapi-krb5-2:armhf (1.12.1+dfsg-19+deb8u4, 1.12.1+dfsg-19+deb8u5), apt:armhf (1.0.9.8.4, 1.0.9.8.5), libirs-export91:armhf (9.9.5.dfsg-9+deb8u16, 9.9.5.dfsg-9+deb8u17), libkrb5-3:armhf (1.12.1+dfsg-19+deb8u4, 1.12.1+dfsg-19+deb8u5), libudev1:armhf (215-17+deb8u8, 215-17+deb8u10), krb5-locales:armhf (1.12.1+dfsg-19+deb8u4, 1.12.1+dfsg-19+deb8u5), libk5crypto3:armhf (1.12.1+dfsg-19+deb8u4, 1.12.1+dfsg-19+deb8u5), libdns-export100:armhf (9.9.5.dfsg-9+deb8u16, 9.9.5.dfsg-9+deb8u17), apache2-bin:armhf (2.4.10-10+deb8u12, 2.4.10-10+deb8u13), libapache2-mod-php5:armhf (5.6.39+dfsg-0+deb8u1, 5.6.40+dfsg-0+deb8u1), systemd-sysv:armhf (215-17+deb8u8, 215-17+deb8u10), libmagic1:armhf (5.22+15-2+deb8u4, 5.22+15-2+deb8u5), libcurl3:armhf (7.38.0-4+deb8u13, 7.38.0-4+deb8u14), libisccc90:armhf (9.9.5.dfsg-9+deb8u16, 9.9.5.dfsg-9+deb8u17), file:armhf (5.22+15-2+deb8u4, 5.22+15-2+deb8u5), systemd:armhf (215-17+deb8u8, 215-17+deb8u10), php5-readline:armhf (5.6.39+dfsg-0+deb8u1, 5.6.40+dfsg-0+deb8u1), libisc-export95:armhf (9.9.5.dfsg-9+deb8u16, 9.9.5.dfsg-9+deb8u17), libsystemd0:armhf (215-17+deb8u8, 215-17+deb8u10), libkrb5support0:armhf (1.12.1+dfsg-19+deb8u4, 1.12.1+dfsg-19+deb8u5), php5:armhf (5.6.39+dfsg-0+deb8u1, 5.6.40+dfsg-0+deb8u1), udev:armhf (215-17+deb8u8, 215-17+deb8u10), curl:armhf (7.38.0-4+deb8u13, 7.38.0-4+deb8u14), libisc95:armhf (9.9.5.dfsg-9+deb8u16, 9.9.5.dfsg-9+deb8u17), libapt-pkg4.12:armhf (1.0.9.8.4, 1.0.9.8.5), libbind9-90:armhf (9.9.5.dfsg-9+deb8u16, 9.9.5.dfsg-9+deb8u17), libdns100:armhf (9.9.5.dfsg-9+deb8u16, 9.9.5.dfsg-9+deb8u17), liblwres90:armhf (9.9.5.dfsg-9+deb8u16, 9.9.5.dfsg-9+deb8u17), openssl:armhf (1.0.1t-1+deb8u10, 1.0.1t-1+deb8u11), apt-utils:armhf (1.0.9.8.4, 1.0.9.8.5), libapt-inst1.5:armhf (1.0.9.8.4, 1.0.9.8.5), libcurl3-gnutls:armhf (7.38.0-4+deb8u13, 7.38.0-4+deb8u14), libisccfg90:armhf (9.9.5.dfsg-9+deb8u16, 9.9.5.dfsg-9+deb8u17), bind9-host:armhf (9.9.5.dfsg-9+deb8u16, 9.9.5.dfsg-9+deb8u17), apache2-utils:armhf (2.4.10-10+deb8u12, 2.4.10-10+deb8u13), libjpeg62-turbo:armhf (1.3.1-12, 1.3.1-12+deb8u1), php5-mysql:armhf (5.6.39+dfsg-0+deb8u1, 5.6.40+dfsg-0+deb8u1), apache2-data:armhf (2.4.10-10+deb8u12, 2.4.10-10+deb8u13), libisccfg-export90:armhf (9.9.5.dfsg-9+deb8u16, 9.9.5.dfsg-9+deb8u17), apache2:armhf (2.4.10-10+deb8u12, 2.4.10-10+deb8u13), php5-common:armhf (5.6.39+dfsg-0+deb8u1, 5.6.40+dfsg-0+deb8u1), php5-cli:armhf (5.6.39+dfsg-0+deb8u1, 5.6.40+dfsg-0+deb8u1), libssl1.0.0:armhf (1.0.1t-1+deb8u10, 1.0.1t-1+deb8u11)
End-Date: 2019-03-11 15:14:04
oO so before the apt update + distupgrade everything worked fine?
This is really strange. Could you activate all TLS/SSL versions and try again? If this works, can you just deactivate the lowest one and try again until we hit the last version that works?
Which Raspbian do you have installed (can be looked up in /etc/issue)?
Yes, before the apt update upgrade everything was running fine. with all protocols activated, even ssl 2, nothing changed to the error message. deactivating the lowest and go up to tls 1.2 doesnt change anything too.
cat /etc/issue
Raspbian GNU/Linux 8 \n \l
noticed maybe some old python pip packages?
pip list --outdated
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.
Package Version Latest Type
cffi 0.8.6 1.12.2 sdist
chardet 2.3.0 3.0.4 wheel
colorama 0.3.2 0.4.1 wheel
cryptography 0.6.1 2.6.1 sdist
html5lib 0.999 1.0.1 wheel
ndg-httpsclient 0.3.2 0.5.1 wheel
ply 3.4 3.11 wheel
pyasn1 0.1.7 0.4.5 wheel
pycparser 2.10 2.19 sdist
requests 2.4.3 2.21.0 wheel
RPi.GPIO 0.6.3 0.6.5 sdist
urllib3 1.9.1 1.24.1 wheel
wheel 0.24.0 0.33.1 wheel
Are all your AlertR instances running on the same host (everything running on this Raspberry Pi) or do you have them distributed on different machines?
the most of them are distributed on different machines, the server and managerclientdatabase as mentioned above are running on different machines too. the update is a cron job, so all rpis getting this error.
instead wasting our time i try to update the rpi version to stretch ... i think this is related to the python or openssl version.
Ok, let me know if it worked out. I have checked at home and I do not have a Raspbian 8 in my network. Every pi is running Raspbian 9 which makes it hard for me to reproduce the issue.
i updated only the alertr server rpi to debian stretch and all is running fine again...