About a week ago I got the email below from Twilio letting me know about security updates and the possibility of compatibility issues on applications using older SSL client libraries. My app is hosted on Heroku, is not using a custom domain and piggy-backs on their SSL. This issue isn't an issue for me, is it? Heroku is usually on top of security and up to date on these things but googling I only find info on setting up SSL for custom domains on Heroku. Anyone have any ideas?
Twilio View Online Reminder: Security Certificate Changes
This is a reminder that on December 1, 2015 at 4:30 PM PT, we’ll be
updating api.twilio.com with a SHA2-signed certificate, a significant
improvement in encryption technology. From the official announcement
on October 8, 2015: Though the vast majority of applications will not
be impacted in any way, there is a possibility that applications using
older SSL client libraries may run into compatibility issues. To
verify that your application is compatible with the new certificate,
we’ve provided a test API endpoint at api.twilio.com:8443. Please note
this endpoint uses a different port from the current default port of
443. Make sure you specify that port in your Twilio SDK.
The validation endpoint will be deprecated on December 1, 2015 when
the new SHA2-signed certificate is deployed to the main Twilio API
endpoint (port 443). Please let us know at help#twilio.com if you have
any questions. We’re always listening and we’re here to help.
Cheers, Team Twilio
Twilio developer evangelist here.
This warning is not about your domain, but the SSL library on the platform on which you make API requests to Twilio.
Since you posted this question not long before the cut off came and it is now gone, I can't give you advice for testing this before the old certificates are removed. Basically, by now, if you are not seeing any errors in your application that makes calls to the Twilio API, then you are safe.
As you said, Heroku are normally on top of things like this and keep their SSL libraries up to date, so you should have nothing to worry about. I just spun up a dyno and ran some tests and everything seemed to work fine, so I suspect you have nothing to worry about.
If you were to have tested this before the change was made, you could have used the test endpoint on port 8443. In Ruby (I'm not sure what language you're using, but it's a good example anyway) you would do this:
require 'twilio-ruby'
account_sid = "AC123..." # your Twilio account sid
auth_token = "xyzabc..." # your Twilio auth token
client = Twilio::REST::Client.new(account_sid, auth_token, port: 8443)
Then, make any call to the API and check that it works over this port.
client.messages.list
If it does work then you are safe and have nothing to worry about.
Related
I want to be able to expose my local machine address to the internet to be able to work with:
Google OAuth2 flow;
Receiving Push-Notifications for changes in my calendars/events;
So that, I need some tool that will expose my local machine URLs to the Internet so Google will be able to use this web hooks.
I found that ngrok with basic(5$) subscription works for me. Free versions doesn't work since I need SSL as it's required by google:
This is your Webhook callback URL, and it must use HTTPS. Note that
the Google Calendar API will be able to send notifications to this
HTTPS address only if there is a valid SSL certificate installed on
your web server. Invalid certificates include: • Self-signed
certificates. • Certificates signed by an untrusted source.
• Certificates that have been revoked. • Certificates that have a
subject that doesn't match the target hostname.
The question is whether there is something else I haven't taken into account that will force me to buy more expensive type of subscription? Maybe some specific requirenments from Google that basic subscription can't work with.
Basic $5 subscription works perfectly. It fits all Google's requirements + it provides static URLs that make it possible to receive PUSH notifications even when you restart your ngrok or computer.
I have a website running on IIS that requires two SSL certificates, one for the main website domain, and one for the traffic coming through a CDN (the assets are served from a different domain name). Both use SSL.
I therefore used the Server Name Indication option when creating the HTTPS bindings in IIS.
The site works fine, I know that users on IE6/Windows XP may experience an issue, but we don't have any/many users visiting our site using that combination so that's not a problem. However, it is an ecommerce site that receives postbacks/callbacks from both PayPal and WorldPay. Here is where we are experiencing an issue. It would seem that neither PayPal or WorldPay's mechanism for posting back payment information understands SNI, therefore we don't get notified that a payment has been made.
I'm not sure what the options are. IIS is telling me to create a default SSL site, but I can't find any instructions online regarding what I should be creating, or what benefit it serves.
Am I going down the right path with this? Can anyone offer any advice on a) whether a default SSL site will fix this issue and b) how to create the default SSL site?
Thanks for your time in advance.
Kind regards,
Dotdev
You don't have to have all your sites configured to require SNI.
From what you're saying, your callbacks from PayPal and WorldPay are on your main site are they?
If this is the case, you can simply edit the binding on your main site so that it does not require SNI, and make sure it is set to "All unassigned" rather than a specific IP address (otherwise it will get in the way of the SNI site).
this year paypal have been informing site owners they need ssl with HTTPS requirement for IPN Postback and SHA-256 etc
I have a website which uses woocommerce, I pass my checkout basket to paypal to process the payment and get a success or fail back to add an order onto my site.
Do I need all this SSL etc on my site even though im using a cart which doesn't process payments itself it hands data to paypal to process?
or can I carry on with no ssl
thanks
No, you don't need SSL on your site. In fact, the notice regarding IPN explicitly says "there is no requirement for HTTPS on the outbound IPN call from PayPal to the merchant's IPN listener".
The changes that are coming are in regards to PayPal's setup. Since part of the process in receiving an IPN is posting it back to PayPal for verification, you need to make sure that your system will still be able to communicate back to PayPal after the changes are done. Since WooCommerce runs on PHP and cURL, this will mean making sure that the underlying SSL libraries are up-to-date:
Most servers use OpenSSL. If this is the case, you need to make sure that you're using at least version 1.0.1.
Some Linux distros (centOS in particular) use NSS instead of OpenSSL. If this is the case, you'll need to make sure that you're using version 3.15.1 or better.
If you're unfortunate enough to have your store hosted on a server running OS X, you'll need to make sure that the server is running OS X 10.8 or better.
Since almost all PHP and cURL setups get all of their SSL/TLS capabilities from one of these libraries, this should be all most people need to do.
I would like to know if there is an option to implement secure websockets (wss://) and client certificate based authentication with twisted ?
I followed the instructions on http://twistedmatrix.com/documents/12.3.0/core/howto/ssl.html, in which the setup of a site over https:// and client certificates is described. Using self signed certs, this works fine. However, things get tricky when Websockets come into play.
Running the whole thing in IE 10 works fine. The client authenticates with his certificate and gains access to the site and may open the Websocket. FF and Chrome, however, won't work. Note that webserver and websocket run on the same port.
In my opinion, it seems that IE somehow stores the authentication of the client and uses it as well for the access to the websocket. FF and Chrome somehow treat the websocket as a different ressource for which no authentication has happened before.
Has anybody experienced the same or somewhat similiar issues or maybe implemented a solution for this?
If needed, I can provide my source code so far.
For all interested readers having the same problem, I finally figured it out.
The solution is to set a session id for the ssl context. Then the browser seems to remember the cert authentication even for subresources like websockets.
This should do it:
contextFactory = twisted.internet.ssl.DefaultOpenSSLContextFactory('keys/server.key',
'keys/server.crt')
ctx = contextFactory.getContext()
ctx.set_verify(
OpenSSL.SSL.VERIFY_PEER | OpenSSL.SSL.VERIFY_CLIENT_ONCE,
verifyCallback
)
## Since we have self-signed certs we have to explicitly
## tell the server to trust them.
ctx.load_verify_locations("keys/ca.crt")
ctx.set_session_id("id")
Lines 1-8 are needed anyway. Whats new is line 9. Here you have to set a session id.
As you've described the issue, this is simply a browser bug, and there's not much you can do about it with Twisted.
Websockets are still, sadly, a somewhat immature technology and bugs like the ones you're seeing are still being worked out. File bugs against the browsers and hope that they get fixed.
Perhaps you could consider implementing server-sent events for non-IE browsers, assuming that the client-cert-auth stuff works for that API / protocol?
I'm working on the application that uses REST web service with SSL. The web service is already in place, identifying itself with the SSL certificate. Even though the certificate seems to be valid, it is still being rejected by iOS. Below are the details:
Web service presents the certificate chain consisting of 3 certificates, the root certificate that is present on this list, the intermediate certificate and finally the web service certificate
The method - (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)space is called each time I send requests to the web service. The comment in RestKit code says "server is using an SSL certificate that the OS can't validate", so I guess I should never reach that method, right?
I tried to access the web service from Safari on the test device, and the certificate is automatically accepted. The same goes for the desktop browsers.
Sslshopper says the certificate is fine.
I can connect to the web service by adding the certificate to the application bundle and handling it the same way I'd do with self-signed certificates, but I want to solve this the proper way. Any help greatly appreciated, especially if someone can point out why Safari on iOS accepts the cert, and my application does not.
Edit: it turns out that I've been using old RestKit version. I created the proof of concept that allowed me to dispatch some requests to my server, and with the RestKit master from today (3rd May 2012) the certificate is accepted. However, I get two calls to connection:canAuthenticateAgainstProtectionSpace:, in both of them I return NO, but it manages to connect properly anyway. So, the new question is, what exactly has changed in RestKit that I can connect properly now. I need to know this because I will have to patch the old version that I'm going to use for release. I will update RestKit afterwards.
Edit: I need to give that back to the RestKit guys, it was not their fault. The web service that I'm trying to connect to is using some kind of gateway which is the source of the problem. There were some fixes from the gateway crew earlier in the day, that's why it worked correctly by the time I managed to perform the tests with the latest RestKit version.