Take a look at below picture.
This page is not loaded over https, so how do modern browsers make sure this page is secure?
asked Nov 17, 2017 at 11:11
-
138What are you trying to secure them against?– BergiNov 17, 2017 at 13:21
-
12@Alpha3031 - using TLS would make it less secure. This would involve opening a socket connection which could potentially be Man in the Middle'd. Since the chrome binary would have to contain the certificate to sign the requests anyone with access to that binary and the connection could read/modify data.– HectorNov 17, 2017 at 16:12
-
7As a side note, if you look in the security section of the development console on the settings page, it will report that "This page is not secure."– Grant DavisNov 18, 2017 at 1:28
-
2Chrome has extra settings if you sign in using a Google account. Therefore, when you are signed in. Your personalized settings are secured via their remote user storage.– ReactgularNov 18, 2017 at 16:20
-
3@SiyuanRen It's not that hard to make an interface in a language like C or C++. There are toolkits to make this even easier. Developers do this all the time. I doubt that laziness is the only reason.– micheal65536Nov 19, 2017 at 15:16
|
Show 6 more comments
7 Answers
What is there to secure it from? It's loaded directly within the browser. There is no connection outside of the local user context of the machine meaning there is nothing to intercept / tamper with.
To modify what you see you'd have to either modify the browser executable, memory space or modify the underlying data used to store the settings. To read the values you would have to be able to read either the browser memory space or underlying files. All of these are end-game. If a malicious actor can do that they have full control and there is no way to protect from it.
-
5Indeed, if a malicious actor could have such control, they could also make connections over http and display it as "https" on the screen, making the user none the wiser.– vszNov 17, 2017 at 12:33
-
3
-
85@Worse_Username - Then they control everything - including the ability to show the "You're viewing a secure Google Chrome page" banner. If someone controls the browser they have full control of absolutely everything done inside of it.– HectorNov 17, 2017 at 16:10
-
4@Worse_Username - Sure process segregation can protect other aspects of the browser from a single process being exploited. But depending on permissions it can likely still read directly into other processes under the same user account. And even if not there is nothing to stop it reading/writing directly to the underlying storage where the settings reside. If they have code execution on your machine as either your user account or an admin you should assume they can control everything that you can.– HectorNov 17, 2017 at 17:07
-
4@Worse_Username I can't imagine a scenario in which someone has only partial control of an application. If they can control part of it, they can gain control of the other parts too. Nov 17, 2017 at 23:39
This page is not loaded over https
It's not loaded over anything. The browser is just displaying it within a browser frame because that frame already has the ability to display web forms so the same code is used to display this form, even though it doesn't come from the web.
-
10
-
1@Mast The data that populates the page may have been downloaded from the web (or some other internet service) at some point. But that's not what the question is asking about. While the browser is running, it surely has its own settings present in memory. Nov 20, 2017 at 11:05
-
2@MichaelPittino, it's not loaded over something any more than your desktop background is. Nov 20, 2017 at 14:46
-
2@PaulDraper Which should also be loaded over OS IO, right? :P Nov 20, 2017 at 17:30
-
1@MichaelPittino no, it shouldn't be "loaded over OS IO" (whatever exactly you mean by this). That would imply e.g. that a particular html page is generated somewhere else and then retrieved as a normal page by some protocol similarly to receiving data from a network connection - e.g like pages retrieved from file:// protocol or localhost IP. It could be like file:// stored static pages, but 's not necessarily like that. The settings page DOM can be simply generated from settings data within the Chrome process, without the page data or anything getting passed through any OS system calls.– PeterisNov 22, 2017 at 10:59
As other answers have said, the page is secure because it is loaded from the browser, not transmitted or accessible by anyone else.
But why does Chrome bother marking such an obviously secure page as secure? To mitigate any phishing attempts. It would be trivial to make a fake 'settings' page and serve it to you to trick you into taking actions. (It seems unlikely to me someone would actually fall for opening a fake settings page, but users' gullibility always amazes me.)
This flag is just one more attempt at trying to make users more aware to avoid silly mistakes, since they are by far the weakest link in the security chain.
answered Nov 17, 2017 at 14:31
-
4The settings page is just that, a HTML page with a URL. To me, it seems like a perfectly plausible attack to have a page which says "Google accidentally logged everyone out of Chrome. Go to chrome:settings (conveniently linked in the page) to log in again", but have the chrome:settings link go to a page hosted on the site and have a phishing page there. Google will probably throw up a phishing warning, but a minority would still click through.– NzallNov 20, 2017 at 13:47
-
@Nzall exactly this. People are dumb as rocks and seem to fall for the most ill conceived lures. Which is why we have to try to help them however we can... Nov 20, 2017 at 13:57
-
"But why does Chrome bother marking such an obviously secure page as secure? To mitigate any phishing attempts." - well, that will primarily help to identify the secure page as secure. It doesn't do much for identifying the insecure page as insecure. Nov 22, 2017 at 7:19
Settings pages are loaded from the local machine, they aren't fetched over a network and therefore can't be subject to a MITM attack. Some of these pages may request actual web resources, but these are usually received over HTTPS.
Also, browser vendors have established certain pseudo-protocols to distinguish the often privileged settings/system URLs from web resources. Examples of these are about: or chrome:. As an additional measure of protection, most of these URLs can't be opened from an unprivileged domain.
That is, a normal website can't even open (or link to) the browser settings page:
(Mozilla Firefox)
(Google Chrome)
answered Nov 17, 2017 at 16:04
Look at the protocol. It is chrome:// not https.
The Internet has dozens of protocols and each one has its own security model (or lack thereof). sftp is secure, ftp is not, irc is not, etc.
file:// only accesses local files on your hard drive. It doesn't communicate across the Internet at all, so it is secure.
chrome:// is similar. It stays within Chrome and is not passed anywhere, so again, secure by nature.
answered Nov 18, 2017 at 16:54
-
For reference on the background of
chrome://: superuser.com/a/517161– kasobanNov 21, 2017 at 14:26
It's just like opening a locally stored text document.
There is no communication with another server while opening the text file and the only way for the contents of the file to be changed is if an attacker has direct access to the system.
It's a secure way to observe the contents of a file.
In the case of the settings page, it's not loaded from a web server, it's just displayed in Chrome as if it were a website.
The pages are loaded locally, which means you can load any chrome:// page without internet connection.
For that reason, theres nothing to intercept since no information ever gets transmitted to the internet (except of course for things like downloading updates, in which case it will use https to download).
