Some API Servers with SSL enabled (namely, mine) require SNI to successfully make an SSL connection. Other API servers (namely, atarashii's) still work with the old SSL handshake. While less secure than SNI, this isn't really a huge security risk. In fact, if you test both the atarashii api and the ramblingahoge api on Qualys SSL Test, you'll find atarashii gets an A and ramblingahoge gets an A+, mostly due to SNI alone.
So, why not just fix it server side? Because, frankly, I couldn't get nginx to cooperate and allow SSL handshakes without enabling SSLv2 and SSLv3, which I'm not going to do, as both of those protocols are thoroughly broken and out of date. The answer then is to fix it client side.
Why is this only a problem now? I...am not entirely sure, but my guess is I beefed up security without adequate testing a while ago, and forgot explicitly what I did. Whoops. This is why we always use configuration management with the configs in a SCM somewhere. Oh well.
This does open the door for further backend fixes. The backend relies pretty heavily on some...questionable code right now, and moving to the requests library could help resolve some of that. That would leave the worst of the clean up for the front end, which also pretty desperately needs it. Now if only I would actually get around to fixing that...
Anyway, I'm going to create this request and leave it open for a few days for comments and concerns, while testing the changes on my own system. Feel free to pull the ssl-fix branch and run it on your own system, it should be stable enough for everyday use.
Some API Servers with SSL enabled (namely, mine) require SNI to successfully make an SSL connection. Other API servers (namely, atarashii's) still work with the old SSL handshake. While less secure than SNI, this isn't really a huge security risk. In fact, if you test both the atarashii api and the ramblingahoge api on Qualys SSL Test, you'll find atarashii gets an A and ramblingahoge gets an A+, mostly due to SNI alone.
So, why not just fix it server side? Because, frankly, I couldn't get nginx to cooperate and allow SSL handshakes without enabling SSLv2 and SSLv3, which I'm not going to do, as both of those protocols are thoroughly broken and out of date. The answer then is to fix it client side.
Why is this only a problem now? I...am not entirely sure, but my guess is I beefed up security without adequate testing a while ago, and forgot explicitly what I did. Whoops. This is why we always use configuration management with the configs in a SCM somewhere. Oh well.
This does open the door for further backend fixes. The backend relies pretty heavily on some...questionable code right now, and moving to the requests library could help resolve some of that. That would leave the worst of the clean up for the front end, which also pretty desperately needs it. Now if only I would actually get around to fixing that...
Anyway, I'm going to create this request and leave it open for a few days for comments and concerns, while testing the changes on my own system. Feel free to pull the ssl-fix branch and run it on your own system, it should be stable enough for everyday use.
Edit to mention: This should fix #19.