Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sense and/or SSL component broken in 0.97.1 #25844

Closed
Mark612 opened this issue Aug 10, 2019 · 16 comments
Closed

Sense and/or SSL component broken in 0.97.1 #25844

Mark612 opened this issue Aug 10, 2019 · 16 comments

Comments

@Mark612
Copy link

Mark612 commented Aug 10, 2019

Home Assistant release with the issue:
0.97.1

Last working Home Assistant release (if known):
0.96.5

Operating environment (Hass.io/Docker/Windows/etc.):
Docker

Component/platform:
sense

Description of problem:
Sense component seems to load, as all the entities show up OK. However, states are not being populated.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

sense:
   email: !secret email
   password: !secret sense_password
   timeout: 35

Traceback (if applicable):

2019-08-10 06:29:43 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/src/app/homeassistant/components/sense/__init__.py", line 64, in async_sense_update
    await hass.data[SENSE_DATA].update_realtime()
  File "/usr/local/lib/python3.7/site-packages/sense_energy/asyncsenseable.py", line 41, in update_realtime
    await self.async_realtime_stream(single=True)
  File "/usr/local/lib/python3.7/site-packages/sense_energy/asyncsenseable.py", line 47, in async_realtime_stream
    async with websockets.connect(url) as ws:
  File "/usr/local/lib/python3.7/site-packages/websockets/py35/client.py", line 2, in __aenter__
    return await self
  File "/usr/local/lib/python3.7/site-packages/websockets/py35/client.py", line 12, in __await_impl__
    transport, protocol = await self._creating_connection
  File "uvloop/loop.pyx", line 1945, in create_connection
  File "uvloop/loop.pyx", line 1942, in uvloop.loop.Loop.create_connection
  File "uvloop/sslproto.pyx", line 500, in uvloop.loop.SSLProtocol._on_handshake_complete
  File "uvloop/sslproto.pyx", line 484, in uvloop.loop.SSLProtocol._do_handshake
  File "/usr/local/lib/python3.7/ssl.py", line 774, in do_handshake
    self._sslobj.do_handshake()

Additional information:
I'm also getting new ssl Errors, that appear to be related:

ssl.SSLError: [SSL: WRONG_SIGNATURE_TYPE] wrong signature type (_ssl.c:1076)
2019-08-10 06:29:48 ERROR (MainThread) [homeassistant.core] Error doing job: SSL handshake failed
Traceback (most recent call last):
  File "uvloop/sslproto.pyx", line 500, in uvloop.loop.SSLProtocol._on_handshake_complete
  File "uvloop/sslproto.pyx", line 484, in uvloop.loop.SSLProtocol._do_handshake
  File "/usr/local/lib/python3.7/ssl.py", line 774, in do_handshake
    self._sslobj.do_handshake()
@Phileep
Copy link

Phileep commented Aug 11, 2019

I have similar complaints seemingly related to ssl.py

I am using the docker image on a synology NAS.

My issue was setting up notify component for smtp.

This has worked for many years unchanged - rolled back to 0.96.5 and worked fine again.

image

@redwngsrul
Copy link

redwngsrul commented Aug 11, 2019

I also experience similar issues related to SSL. Docker HASS running in container station.

I use a command line sensor to query the status of my Foscam camera statuses. The latest update seems to have broke my curl command. HASS container on a QNAP NAS. This is the command I send:

curl -k --silent "https://192.168.1.97:443/cgi-bin/CGIProxy.fcgi?cmd=getDevState&usr=[username]&pwd=[password]" | grep -oP "(?<=motionDetectAlarm>).*?(?=</motionDetectAlarm>)" 

and it worked before 0.97, but when I tried to run the command via the shell, I get this error:

curl: (35) error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol 

@Mark612 Mark612 changed the title Sense component registers but states not updating Sense and/or SSL component broken in 0.97.1 Aug 11, 2019
@probot-home-assistant
Copy link

Hey there @kbickar, mind taking a look at this issue as its been labeled with a integration (sense) you are listed as a codeowner for? Thanks!

@kbickar
Copy link
Contributor

kbickar commented Aug 13, 2019

Is this the same issue reported here: scottbonline/sense#30?

In that case it was people with outdated openssl versions. I guess we could make the change to support them if they're unable to update

@Mark612
Copy link
Author

Mark612 commented Aug 13, 2019

Following the link provided, and then changing in sense_energy/senseable.py:

  •        ws = create_connection(url, timeout=self.wss_timeout)
    
  •        ws = create_connection(url, timeout=self.wss_timeout, sslopt={'ciphers': 'DEFAULT@SECLEVEL=1'})
    

Does not fix the issue, same error.

In addition, openssl is updated to the latest. And the previous version of HA docker sense works.

@kbickar
Copy link
Contributor

kbickar commented Aug 13, 2019

There weren't any changes in the sense component or library since 0.95 - I wonder if something else SSL related changed in HA?

@Mark612
Copy link
Author

Mark612 commented Aug 14, 2019

@frenck - could we move this to a core/ssl label and assignment? The issue seems to go beyond the sense component. Thank you.

@Mark612
Copy link
Author

Mark612 commented Aug 17, 2019

I rolled back to 0.96.5, which fixed the issue.
Hopefully this bug is fixed in a later release...

@Phileep
Copy link

Phileep commented Aug 18, 2019

The version of openssl appears to have changed between the dockerbuild for 0.96 and 0.97

96.5 is using openssl 1.1.0k 28 May 2019

97.x is using openssl 1.1.1c 28 May 2019

@redwngsrul
Copy link

redwngsrul commented Aug 18, 2019

In my dockerbuild for 0.97, I manually rolled back the openssl version to the 1.1.0k, but my log is now showing this error when first booting up the HASS instance.

2019-08-17 22:24:57 ERROR (MainThread) [homeassistant.core] Error doing job: SSL handshake failed                                   
Traceback (most recent call last):                                                                                                  
  File "uvloop/sslproto.pyx", line 500, in uvloop.loop.SSLProtocol._on_handshake_complete                                           
  File "uvloop/sslproto.pyx", line 484, in uvloop.loop.SSLProtocol._do_handshake                                                    
  File "/usr/local/lib/python3.7/ssl.py", line 774, in do_handshake                                                                 
    self._sslobj.do_handshake()                                                                                                     
ssl.SSLError: [SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3 alert certificate unknown (_ssl.c:1076)

but I can confirm that my shell command that was previously returning errors is now working!

curl -k -v "https://192.168.1.97:443/cgi-bin/CGIProxy.fcgi?cmd=getDevState&usr=[username]&pwd=[password]" | grep -oP "(?<=motionDetectAlarm>).*?(?=</motionDetectAlarm>)"

@kbickar
Copy link
Contributor

kbickar commented Aug 18, 2019

Looking at this SO thread , it seems the root certificates need to be installed for the new openssl

@redwngsrul
Copy link

Just a little leery, that thread is years old

@Mark612
Copy link
Author

Mark612 commented Aug 18, 2019

The change to 1.1.1 takes us to TLS1.3, which has significant changes including the need to use new ciphersuites. Read here.

@fjfricke
Copy link

I can't use tts say anymore on my DMR media player and I'm getting the same ssl handshake error. Is that somehow related or a different issue?

@pergolafabio
Copy link

I also have issues , I am using curl commands with -k option to ignore ssl issues, I did it on 127.0.0.1, all worked fine...
Now I have a huge delay if I execute them...

So now I use for now the -X option with nabucasa url, then it's instant...

Not sure how I can resolve it... How can I maybe use the -X option with 127.0.0.1 ?

@Mark612
Copy link
Author

Mark612 commented Sep 1, 2019

This appears fixed in 0.98.1. It is working fine with the new docker base image.

@frenck frenck closed this as completed Sep 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants