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?
Related
I was studying Websockets (wss) and I am a little confused about their use of SSL. I hope some of you will be able to clarify some things that cause the most confusion to me.
Use scenario
Let's say I have an HTTPS secured website with a certificate signed by CA. I would like to communicate with a custom app in real-time (using the WebSockets) running on an external server that is not using the same domain (the site is for example www.mysite.com and the server is www.notmysite.com).
The confusion part
When the WebSocket client (wss) is connecting to the remote server, what SSL certificate does it use? Is it of the origin website, or of the server it is trying to connect to?
Given the scenario, can a connection be established with a single-domain SSL certificate - only for the website (www.mysite.com) where we know the private key and therefore we should be able to decrypt the encrypted data?
If question no. 2 is false, would multi-domain certificate containing both urls fix the problem?
The background story
I was trying to make a WebSocket server in .NET C#. I managed to get it working with HTTP however when I tried the code on HTTPS secured website I was presented with an encrypted text I could not really work with. That is why I bought an SSL certificate and put it on the website thinking that if I have the private key I can decrypt the data and communicate with the client (basically question no.2). Though I was only presented with different errors regarding cryptography. I was trying to figure this out for over a week and my progress and frustration can be seen in my other questions such as:
C# RSA decrypt parameter is incorrect and
AuthenticateAsServer() error
Then I figured out I may need to look at it from a different point and that's when I came up with this theory. I hope some of you will be able to end my suffering with an explanation of why what I did was wrong. I appreciate any help. Thank you very much.
I am not 100% sure if the multi-domain SSL certificate solved this issue since I combined it with using a premade library (WebsocketsSharp) which along with the new multi-domain certificate works perfectly. In my opinion, the multi-domain certificate is needed if you want to communicate between two different servers (either website and server or two servers).
I hope I will save some future headaches.
So I've moved a website to another server (from wordpress) and have transferred the domain. Previously, it had a ssl certificate in wordpress, but not now (not needed). So now, when I try to access it in a browser, it automatically redirects to https. I know how to remove it from the browser cache, but the problem is, all the users that had accessed the website before will have the same problem and they won't know how to solve it or won't be even interested in doing so. My client could be losing a lot of visitors because of that.
Is there any way to solve that without buying a ssl certificate? I only need to solve the browser cache problem, the website is all new and everything else works fine.
Thanks
No, you cannot.
The mechanism you refer to is known as Strict Transport Security, and is specifically designed to prevent what you are trying to do.
However, you do not have to buy a certificate, you can get them for free using Let's Encrypt.
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.
Is there a https header on the server, or JavaScript method in the browser, that will let us detect when the user has intentionally bypassed the security certificate, or any other way to detect and report this kind of situation? (We are using Linux / Apache / jQuery.)
The Web is filled with ways to routinely skip the warning, but I haven't been able to find a single thing about detecting when users skip it - just the horrifying statistic that 70% of users bypass the warning as quick as they can. (How do they measure that?)
We operate a web application that lets teachers make and administer tests. Teachers are connecting to unauthorized WiFi networks, getting invalid certificate warnings, and clicking on the browser's "accept anyway" feature so they can get to our application despite having certificate that is not authenticated. We want to understand how often this happens, and who is doing it, and progress to stopping it.
I should note that there are schools that proxy requests through their own server, with their own certificate, and we are OK with this - it's the "ignore and connect anyway" connections that we want to measure and mitigate, because those are the ones that students are setting up, without access to their own CA but ample access to lazy users.
One way to make sure that the client has seen the server certificate you sent is to use client-certificate authentication. One of the last steps of the SSL/TLS handshake when using client-certificate authentication consists of a hash of all the handshake messages signed with the client's private key.
A side effect of this is that, if the client didn't see the exact same server certificate, the server wouldn't be able to validate this signed hash coming from the client.
This certainly doesn't necessarily mean that the client checked the certificate as it should have (i.e. whether the certificate was trusted and belonged to the server the client intended to contact), but at least the server has a way there was no fake cert in the middle.
HSTS (which you mention) also has a way to make the client enforce these checks (see Section 8.4 of RFC 6797). However, it only works if the client already knows HSTS needs to be used (either as a pre-loaded host, or after a first visit), and of course relies on the client supporting HSTS (browser support is still limited).
Not sure what you mean by bypassing HTTPS. If you mean they can visit your URI without HTTPS, that means you need to block HTTP access in Apache's .htaccess, httpd.conf, or default-ssl config files. Broken padlock could mean a number of different things so it's not clear which problem you're having. You can test your site for SSL security problems here:
https://www.ssllabs.com/ssltest/
Edit:
You can compare the fingerprint of the SSL certificate on the server and on the client to make sure they match (if the client is able to get the fingerprint). That should prevent man-in-the-middle attacks with bogus certificates.
Article
and here's an answer for doing this on the server side of things. It sounds like the best way to avoid interception is to authenticate the client with their own certificate.
There is no way to detect this - the user is the only one who can see if the padlock is green and locked or red and broken.
Firefox will do this by extension and through xhtml, but it is, as of now, the only browser to support this.
I was looking for HSTS. Here is how it works and how to implement it.
TL;DR: Header add Strict-Transport-Security "max-age=15768000 includeSubDomains"
I apologize, I know this is a very short question but Google doesn't seem to help (I guess I'm not searching for the correct phrase or set of keywords).
If I have a site not protected by SSL and it makes an api call to an https site, is that information secure or do I need to have SSL as well?
I want to make sure I keep my users' data secure.
Only data in the API call (request) needs to be protected. Data returned by the API (response) to my (non-SSL) site isn't meaningful or sensitive.
Thanks in advance.
The call to the SSL site will be protected, but if it's multihop (client to non SSL to SSL site) and the data on first hop is plain text.
However as #VictorRonin says, security is a much bigger concern than just SSL.
The call is protected. Your website talking to another website (protected by SLL) will send and get information inside of protected channel.
However, it's hard to say whether your users data is secure. Security requires a lot more than just usage of SSL.
I also got the same problems.
I'm using 16 bits micro connect to net by Wifi's AT command .
after connected in transparent mode. normally I can send some simple text (HTTP ) to request content from every web page.(if those webpages not need SSL).
this makes programing fun and easy.
But these few years. life got stuck almost webpage use SSL. mean programming need more complex step to reach content.
but the most serious things is that the CA (cert auth) cannot use forever it has expired time !!!
This mean hardware device have to modified CA data frequently . so it's not practical for small iot firm .
However I found a way even it's not the best by using thingspeak.com (ThingHTTP)
with ThingHTTP you can request without SSL to any website which need SSL
I hope in the future there are more iot cloud or even some webpage turn to use old method (HTTP) in case of that data no need secure.
In my opinion user can encode/decode the data by themself instead of secure everything in webpage.
Thnks