Is it possible to write a chrome extension that will bypass certificate errors automatically?
I am dealing with automation scripts that deal 100% of the time with self-signed certificates coming from appliance-type web servers. The browser wont/cant be used for regular internet navigation. Is this possible?
Apparently, this is not possible. As stated in this related SO post 1 and SO post 2, it is not possible to bypass certificate exception automatically. You have to add manually the certificates, see superuser post for additional information. Hope this helps.
Related
Very strange, I can surf to every website I try. Except subdomains of google.com.
ex; firebase.google.com or photos.google.com or analytics.google.com ...
(I am enable to do normal google searches though)
When I go to these sites Google Chrome returns following error:
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
And it says x.google.com doesn't use a supported protocol.
Same result when using FireFox:
SSL_ERROR_NO_CYPHER_OVERLAP
Microsoft Edge also raises an error, saying something about the TLS-configuration
As I found it very difficult to believe this is an issue caused by the Google side, I tried two things:
Cleared my cookies
Cleared SSL certificates
But no result.. Any idea's?
You may get this error as the website is still encrypted with the older RC4 or SHA-1 algorithm.
You must check the status of the Cipher-suit of the website, it will help you to understand the correct concern and you can solve the issue.
Looks like Push notifications are finally usable for web-apps! Unfortunately, this requires https for ServiceWorker, which not all sites may have.
One thing I noticed in the spec it mentions:
if r's url's scheme is not one of "http" and "https", then:
Throw a TypeError."
So I'm confused - can the site be http, as long as it includes a serviceworker that is from https? For example, mydomain.com could include an https serviceworker from https://anotherdomain.com?
Another standard, web-api simple-push, doesn't mention requiring https (likely an omission in the documentation?), and "The user experience on Firefox Desktop has not been drawn out yet". Is the documentation on this outdated, or is push really only supported in FirefoxOS??
Simple-push, that is the current push solution in Firefox OS doesn't have anything to do with ServiceWorkers.
The next generation of push, implemented by both Google and Mozilla will be done through ServiceWorkers:
Push API spec
In that case yes, your content will need to be served over HTTPS.
Probably you will be interested in the LetsEncrypt initiative:
letsencrypt.org
A new certification authority that will help developers to transition their content over HTTPS.
Also just for development purposes, both Google and Mozilla implementations of ServiceWorkers allow you to bypass the check of the secure content, if you develop against localhost.
In the case of Mozilla you will need to enable the flag:
devtools.serviceWorkers.testing.enabled: true
But again this will be just for development, and AFAIK, Mozilla push landed or is about to land, and will be available in the nightly builds, you can follow the work here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1038811
No, the new generation of push notifications (i.e. Push API) requires HTTPS.
If you need to add push notifications to a website without HTTPS you can use a third-party service like Pushpad (I am the founder) that delivers notifications on your behalf.
The text you cited from the spec is from the Cache.addAll() section (5.4).
Here's the summary of addAll() on MDN:
The addAll() method of the Cache interface takes an array of URLS, retrieves them, and adds the resulting response objects to the given cache. The request objects created during retrieval become keys to the stored response operations.
Service workers can request & cache URLs that are either HTTP or HTTPS, but a Service Worker itself can only work in its registered Scope (which must be HTTPS).
simple-push is not related to Service Workers; it seems comparable to the approaches other platforms have taken:
Apple Push Notifications
Google Cloud Messaging
I found a nice bypass workaround to allow notifications from websites and domains without SSL, hence http:// and not https:// for Firefox.
Firefox holds a file inside the Mozilla directory called permissions.sqlite which is a sqlite database file that holds the permissions for domains. You can add your domain there http://yourdomainname with permissions for notifications and it will work.
I have created a demonstration for Windows here https://gist.github.com/caviv/8df5fa11a98e0e33557f75215f691d54 in golang
I want my Chrome extension to collect information about how the current browser tab negotiated its secure connection.
In particular, I want to know the protocol and the cypher/auth & key exchange mechanisms used in the HTTPS connection: SSL3? TLS 1.2? And those ugly strings like AES_128_GCM or CHACHA20_POLY1305, ECDHE_RSA or ECDHE_ECDSA.
Is this even possibile?
Within the API index, the best fitting module seems to be chrome.webRequest. But I can't see any means to gather connection data. Am I missing something?
You cannot get any information about the TLS connection via the Chrome extension APIs. A few days ago, a popular feature request on Chromium's issue tracker was marked as WontFix because of the complexity of implementing such a feature in Chrome (Issue 107793: Provide information about the TLS connections to extensions via the webRequest API).
The only way to get the certificate information in Chrome is by clicking on the lock icon, then the Connection tab.
I developed a chrome extension which communicates with IP phones.
The communication is done in a event page which is sending POST requests via the XMLHttpRequest object.
Because the hostname or IP address of the phone is configured in the options page I added optional_permissions to the manifest file and request them from the user after saving the options with chrome.permissions.request.
Cross-Origin XHR works now without any problems until I restart chrome...
After restarting chrome it seems like the requested permission is lost and I get the typical
is not allowed by Access-Control-Allow-Origin error.
When I click on the extensions permissions I can also see that my requested permission is no longer listed.
Because the chrome.permissions.request is only working for a user gesture I can't request it during the load of my extension or on the fly. If I request the permission again in my options page I don't get asked again whether I want to allow it or not put the permission is granted and everything works again as usual.
Is there a way to get this permission granted persistent after requesting it? I only want the extension to have access to the endpoints it needs.
Thank you very much.
For me the following reported issue answered my question:
Issue 158004: chrome.permissions.request support for user-supplied URL.
To make it clear: It is not possible to request a subset of the permissions defined in optional_permissions. If you define http://*/* then you need to request exactly this string! A subset like http://example.org/* wont work!
Here is a quote from a comment in the issue description which makes that clear:
"There's no wildcard handling, just plain string comparison between the URLPatterns"
The Issue has been fixed in Revision 182287
The only thing left is to cross your fingers that this fix gets included in a upcomming chrome release soon. We'll have to use the bloody Access your data on all websites permission in the meanwhile.
Trying to set up an encrypted connection for an intranet site. It's for a small company and not dealing with any sensitive information, but still would like to avoid login and password information sending in the clear. Would also like to avoid having to buy a certificate if possible.
I tried creating a certificate with OpenSSL and got everything set up and the site works over an HTTPS connection, but the web browsers are all showing warning messages. So, I googled around and found that I could add the certificate to Windows' Trusted Root Certification Authorities. I tried this, but am still getting the warning messages and "red x" https logo. Also tried importing the certificate into Chrome through the options screen but no luck.
How can I get my internal machines to trust my self-signed SSL certificate and not show a warning message?
I think Mr. Leahy's suggestion to use a name with DNS-like qualification would work. Here's Chromium patch information related to the error:
http://groups.google.com/a/chromium.org/group/chromium-checkins/msg/9fe59a981479aa44?pli=1 (r62178)
If the host name denotes an "intranet host", which in the code means one with either no dot in the name or a dot at the end, then it is considered non-unique, and you get the warning. After quickly looking through other patches involving the warning, I didn't find a way to tell Chrome to relax about the warning.
Im not sure this will apply to your question but I had a similar experience a few days back where chrome would show an insecure site (red cross through the EV ssl)
In my case it was because some links from google apis were over http not https
thus MAKE SURE ALL YOUR EXTERNAL RESOURCES ARE CALLED OVER HTTPS not http!
I stumbled across the same issue today and found a stunningly simple solution:
It turns out that a bad certificate override is displayed during the entire chrome session even if the certificate has been validated or renewed in the meantime.
Restarting chrome fixes that.
If the certificate warning is still present after the restart, then You will have to look at the other answers.