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.
Related
My web client application is setting HTTP POST requests via fetch API.
I see that OPTIONS preflight requests are sent via debugging proxy (Charles Proxy), but they are not displayed in Google Chrome Developer Tools\Network tab.
I don't have any filters setup on the network tab. I remember OPTIONS requests being visible there, but not anymore. How do I bring them back?
You'll need to go to: chrome://flags/#out-of-blink-cors, disable the flag, and restart Chrome.
This is an expected behavior change according to:
https://bugs.chromium.org/p/chromium/issues/detail?id=995740#c1
I originally came across this via:
https://support.google.com/chrome/thread/11089651?hl=en
As of 2021 in CHROME the OPTIONS request is visible in the NETWORK tab filter OTHER requests
To see it together with XHR just CTRL+click and pick the request filters you want to see.
UPDATE (April 17) Chrome Version 90.0.4430.72 has made the options requests hidden again :(
Chrome 81 does not seem to display anything even after changing the option and restarting on my computer.
As an alternative solution, I started to use Firefox and its Network tab for development.
https://getfirefox.com
I'm Takashi from Chromium Project, and drove the Out-Of-Blink/Render CORS project.
The project intended to introduce a process isolated CORS implementation for better security and privacy, and many of new network related features rely on this new implementation. Unfortunately we temporarily disabled preflight support in DevTools as it turned out continuing to support it weakens security and privacy. Sorry for inconvenience during this period.
Good news is now Chrome 83 implements the CORS preflight DevTools support again in a security preserved way. So you can monitor the CORS preflight requests as you could do before the Out-Of-Blink/Renderer CORS.
Best,
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.
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 am writing a basic web application that uses <iframe> elements for certain features.
The entire site uses https, including the links to and from the iframe, but when I view the website using Google Chrome and right-click on the displayed frame and look at "View Frame Info" --> Connection, I see the following message:
Your connection to www.example.com is not encrypted
The connection uses TLS 1.1.
The connection is encrypted using AES_256_CBC, with SHA1 for message authentication and ECDHE_RSA as the key exchange mechanism.
Confusingly, it says that the connection is not encrypted ... and then it says that it IS encrypted.
I thought that whenever you use https://, the content is encrypted. Am I wrong? Or is Google Chrome referring to something else?
I ended up posting this issue to the Chromium bug discussion board and someone there indicated that it's a bug.
I am trying to build an extension that would notify a user when new version of Chrome is available.
I tried to inspect network traffic when Chrome is checking for an update and it is sending a request to http://74.125.95.113/service/update2?w=3:{long_encoded_string} page that returns XML with information I need:
<?xml version="1.0" encoding="UTF-8"?>
<gupdate xmlns="http://www.google.com/update2/response" protocol="2.0" server="prod">
<daystart elapsed_seconds="31272"/>
<app appid="{8A69D345-D564-463C-AFF1-A69D9E530F96}" status="ok">
<updatecheck status="noupdate"/>
<ping status="ok"/>
</app>
</gupdate>
Besides sending {long_encoded_string} as URL parameter it is also sending some encoded cookie.
Maybe someone familiar with Chrome build process can shed some light on those encoded strings and how to build them? Maybe there is another easier way (I have a feeling that string encoding is a dead end for me)?
Google Chrome uses omaha to do updates to clients. The protocol is described here: http://omaha.googlecode.com/svn/wiki/cup.html. One thing you have to notice is that Google Chrome automatically downloads the update to your computer and then notifies (via icon on the tool menu). Unless you force check by opening the about dialog (in Windows).
As you have noticed, the Chrome GUID is {8A69D345-D564-463c-AFF1-A69D9E530F96}
The best way to see how Google Chrome is updating is to check the source code which is public. Google just ifdefs their version of Chrome in Chromium.
Google Chrome Code
The base class where all the updates happen is in UpgradeDetector, it basically checks for an upgrade every 1 hour for the dev channel and once a day for all the other channels and builds (stable / beta). The Chromium way to do a scheduled events is through Tasks, in this case it is caleld a DetectUpgradeTask which checks for a specific BrowserDistribution::GetSpecificDistribution. There are many browser distributions, for Windows it is called GoogleChromeDistribution which is in charge to figure out what the version that needs to be update..
So why am I saying all this, Google Chrome is just querying registry settings and local files to figure out if a new update exists. The the UpgradeDetector just compares the distributions if they are the same. The implies that Omaha does the whole update mechanism. And the best part to figure out what omaha does is to look at their omaha update protocol.
The Omaha Protocol
From quickly glancing at the protocol, the approach your taking is the correct one, but you have to figure out the public key. In this case, the w, which differs for every request. You can read more about this in the "Protocol observations" in the omaha update protocol. It does this to do a securely check for download updates and they do this to protect the communication. They want the connection that checks for updates to be authentic and fresh so an attacker cannot replace or modify the message nor trick the client to upgrading a vulnerable version.
So what now
It isn't just a simple request to the server to do an update check. The Omaha client protocol provides an alternative to SSL for update checks and does client-server requests to see if its a valid connection. They are doing all this to protect the communication as explained before.
Unfortunately I don't think there is a "Chrome Extension" HTML'sh way to do this unless you implement that handshake yourself using NPAPI. Don't take my word for granted, I might be totally wrong :) Unless you can do the handshake all through XHR requests.
Since you want to check if Chrome has been updated and not installed, you have to verify that a new distribution has been downloaded as explained above in the code GoogleChromeDistribution which definitely requires NPAPI to read the registry.