Meraki Device Tracker SSL Error

[smccloud]

Home Assistant release with the issue:

0.73.2

Last working Home Assistant release (if known):
0.72.0

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

Docker on Debian Linux

Component/platform:

Meraki Device Tracker

Description of problem:
Trying to validate the Post URL in the Meraki dashboard I get an error of "Response other than 200". In the HA log I get

2018-07-18 08:39:32 ERROR (MainThread) [homeassistant.core] Error doing job: SSL error errno:1 reason: NO_SHARED_CIPHER
Traceback (most recent call last):
  File "uvloop/sslproto.pyx", line 497, in uvloop.loop.SSLProtocol.data_received
  File "uvloop/sslproto.pyx", line 204, in uvloop.loop._SSLPipe.feed_ssldata
  File "uvloop/sslproto.pyx", line 171, in uvloop.loop._SSLPipe.feed_ssldata
  File "/usr/local/lib/python3.6/ssl.py", line 689, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:841)

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

- platform: meraki
  secret: !secret meraki_secret
  validator: !secret meraki_validator

Traceback (if applicable):

Additional information:
Seems to be related to deprecation of older SSL cipher suites.

[balloob]

Correct. We are using the Mozilla suggested ciphers. Looks like Meraki is not supporting modern ciphers?

[smccloud]

#15546 did not resolve this issue.

[ghost]

I have the same issue.

See #15303

[chriskacerguis]

Same issue with HA 0.75.2 running the Docker version.

ssl.SSLError: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:841)
2018-08-06 15:33:49 ERROR (MainThread) [homeassistant.core] Error doing job: SSL error errno:1 reason: NO_SHARED_CIPHER
Traceback (most recent call last):
  File "uvloop/sslproto.pyx", line 504, in uvloop.loop.SSLProtocol.data_received
  File "uvloop/sslproto.pyx", line 204, in uvloop.loop._SSLPipe.feed_ssldata
  File "uvloop/sslproto.pyx", line 171, in uvloop.loop._SSLPipe.feed_ssldata
  File "/usr/local/lib/python3.6/ssl.py", line 689, in do_handshake
    self._sslobj.do_handshake()

[chriskacerguis]

FWIW - I looked at #15546 and that is for outgoing connections. This component (Meraki) would be an incoming web hook (so that PR would have no effect on this)

[chriskacerguis]

I've been working with Meraki on this, here is the issue:

The Meraki Dashboard is proposing the following cyphers:

• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
• TLS_EMPTY_RENEGOTIATION_INFO_SCSV

However, HA is only accepting the following:

• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-CHACHA20-POLY1305
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-RSA-AES256-SHA384
• ECDHE-RSA-AES128-SHA256

So, there is no match. I'm seeing if I can escalate this with Meraki so they can add one of those, but I suspect that it would be easier for HA to accept one of the ones that Meraki is proposing.

[chriskacerguis]

@balloob could I call your attention here? I'm sure you are swamped, and I want to be super respectful of your time, but it seems like this may be a larger issue. It seems that HA is accepting only a very limited set of cyphers (not, necessary a bad thing, however it would seem that other companies aren't as "on top of security".../sigh).

Would you mind chiming in here when you have a moment? I didn't want to open a bunch of tickets and send devs down lots of rabbit holes.

Thank you so much for all you have done (and continue to do) for the community and HA!

[balloob]

We are following the Mozilla modern compatibility configuration for SSL: https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility

I don't think that it's a good idea to downgrade the security of Home Assistant for a single integration.

[chriskacerguis]

Hi @balloob thank you for taking the time to chime in :)

This issue seems to be happening in a few places (for example #15579 (comment) ).

Looking over that doc, I get what you are saying, that said their default is "Intermediate compatibility", perhaps, at least for the time being, that would provide better compatibility.

OR perhaps an option could be added to allow the user to select which compatibility mode to use. Apologies, I'm not a Python dev...so that would be hard for me to do.

Thoughts?

[rpitera]

Definitely happening in more than one integration. While I agree it's never a good idea to downgrade the security of HASS, maybe as a interim step provide a logged warning and identify which integration or integrations is/are at fault so that users can then go to the vendor to seek their assistance in getting them to upgrading their cyphers? Just a thought.

[gidadavid]

@balloob Are you working on this issue? There are a great number of user which experience this Issue
( #15579 )
Or is there another way, I could remove these strings full of errors. I can´t fix my configuration.yaml if I m not be able to see other errors

Greetings Gideon

[balloob]

It is difficult to figure out the integration because of the handshake failure, the client never tells us what path it wants to reach.