You have certainly seen a ‘twitter card’. Its an image with a bit of text in it, something like this one.
Behind the scenes what twitter does is fetch the URL you give it, look for some meta tags, and build. You can test your twitter cards at their ‘card validator’.
Now, for me, sometime after sept 5, the cards broke. This puzzled me since I had not changed the config of my web server. And the validator was no help, it just says “Error: Fetching the page failed because other errors”. Nice.
So, I look online. Tons of people had this problem. It was attributed to various things (ghosts, goblins, typos, …). But one thread kept coming through, SSL. Most people referred to SNI as an issue.
I checked my server config on ssllabs.com, A+, no problems reported. My server has an entry for blog.donbowman.ca as an SNI, so not that. Hmm.
So I look at the server logs (nginx). It has nothing to say. Every time I hit the validator, no entry is created at all. tcpdump verifies that a TCP connection is occurring.
I look in the capture, I see the cipher suite the client (twitter) will accept, and compare it against what my server offers. They match. But, I see “TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)” as an error created. Hmm.
To confirm I added the keyword ‘debug’ to the error.log in nginx. This produced the same log. OK.
I looked at the ciphers I expose:
ssl_ciphers ‘ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384!AES128:!3DES’;
For sure, based on the client wanting ECDHE-ECDSA-AES-256GCM-SHA384, this is there.
For kicks I make the ciphers be:
ssl_ciphers ‘EECDH+ECDSA+AESGCM’
No dice either.
I later discover that if I remove the ‘!AES128’ it works. Specifically:
ssl_ciphers ‘ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:!3DES’;
So why did it not work? Closest I can see is this, an issue in openssl. An apt update on the server had brought in a new security patch of openssl, and now even though we have a match, it doesn’t find the right curve since it does a one-pass match. See this issue for more details.
So is re-enabling AES128 the right answer? No. Anyone else have a cipher line for nginx that works w/ twitter cards? I posed in the twitter dev forums, no answer there (but lots of other people with similar threads).
Leave a Reply