According to MDN documentation about Web Crypto Subtle API, and this answer:
TypeError, 'digest' of undefined, in development environment
I understood that the API only works on localhost or over HTTPS protocol.
So, to validate this point, I deployed a front-end app using this API, behind a NGinx proxy on a desktop and tried to connect to this app from another computer.
Using Chrome, the code had been blocked because I'm not connecting on HTTP.
But using Firefox, these works without any alert. Did I miss something about Firefox?
Ok, this was an issue and had been fixed in the latest release.
https://bugzilla.mozilla.org/show_bug.cgi?id=1333140
Up to version 74, you were able to use WebCrypto API outside a secure context.
I updated to v75 and it's fine.
Related
I set up Burp to intercept https requests. I could see the packets of all https websites like goole, facebook. The website web.whatsapp.com is not loading completely on using with Burp proxy. I am getting this error on webpage
WebSocket connection to 'wss://web.whatsapp.com/ws' failed: WebSocket
opening handshake timed out
What may be the reason?
Like many popular apps, WhatsApp is using certificate pinning which makes sniffing packages way more difficult (as the application only trusts one certificate). That being said Burp Suite offers some solutions for iOS, which unfortunately only work if your device is Jailbroken (If this is the case here is what you have to do).
I hope this helps!
Recently we have configured SSL to open WSS on our RESTCOMM server, as we got the issue of "getUserMedia()" deprecation issue because of insecure origin issue by chromium fix.
We managed to get WSS working and we can open RESTCOM Admin portal via HTTPs over 8443 port and even OLYMPUS is working too.
But because we have configured a SSL on RESTCOM Server i think even the REST Client API calls need to be on HTTPS too. Am icorrect?
Becuase when we use the HTTP based URLs for programmatically adding clients by invoking REST Client APIs of RESTCOMM, then we are getting SSl certificate issues and the reason for this i think is that we have configured SSL cert to address the getUserMedia() security issue by CHROMIUM fix.
can i request any solution or work around for this pls.
thanks in advance
ias
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.
I'm getting the above mention error when my client update their device to iOS 7.1, and then try to update our app from the AppCenter.
After some searching, i found a post with a similar problem here. But then since i'm in an environment where by the client is using AppCenter to update the apps, i can't be using USB to plugin and install the app for them.
Is there any workaround for downloads via AppCenter until a support is released?
A change was introduced to iOS as of iOS 7.1 that requires OTA application installation to take place over HTTPS (rather than HTTP), and no provision exists to allow the user to continue to accept the old behavior (i.e., to permit application installation over HTTP). It is my understanding that this was done as a security enhancement.
In order to do application installations on iOS 7.1 from Application Center, you would need to configure your Application Center to use HTTPS rather than HTTP, using a certificate that will be accepted as valid by your iOS device - that is, either issued by a recognized public CA, or issued by a private CA that you have set up your mobile devices to accept. You can find more information about how to perform this configuration here:
http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/topic/com.ibm.worklight.installconfig.doc/appcenter/c_ac_ssl_config.html
I would add some details. (Just work out this question)
We use self developed app center for our customers, to distribute demo/report apps.
You need SSL certificate. (see the post above)
You can buy any kind of public certificate . In some cases you can use self signed certificate previously installed on iOS device by Apple Configurator.
It seems that you don’t have to use https everywhere. Secure URL (https) must have a link to .plist only. The app center web site url and package .ipa url can still be under http.
… and shame on Apple that invents new ways to make developer life hard.
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?