24

Take a look at below picture.

settings page

This page is not loaded over https, so how do modern browsers make sure this page is secure?

Anders
  • 64,406
  • 24
  • 178
  • 215
ThankYouSRT
  • 1,275
  • 3
  • 12
  • 15
  • 138
    What are you trying to secure them against? – Bergi Nov 17 '17 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. – Hector Nov 17 '17 at 16:12
  • 7
    As 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."](https://i.stack.imgur.com/fwflO.png) – Grant Davis Nov 18 '17 at 01:28
  • 2
    Chrome 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. – Reactgular Nov 18 '17 at 16:20
  • 2
    @MichealJohnson: Because writing an UI in HTML+CSS+JS is far easier than C++. – Siyuan Ren Nov 19 '17 at 05:49
  • @MichealJohnson, and here I was, opening this and thinking that would have been exactly the point. – ilkkachu Nov 19 '17 at 11:49
  • 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. – Micheal Johnson Nov 19 '17 at 15:16
  • 1
    @MichealJohnson: here we have the developers of one of the best cross platform, cross technology UI toolkit in the world: HTML+CSS+JS, and you are suggesting that they are lazy if they don't use another toolkit to develop their own UI? Would Java developers also be llazy for developing Eclipse in Java? – Lie Ryan Nov 21 '17 at 10:24
  • 1
    @LieRyan No you're missing the point. It's not a *lot* of work to develop a UI using a standard toolkit, it would probably take an average developer about a week or two to reimplement the Firefox settings page in GTK (for example, or whatever GUI toolkit they're using). It's something that every application developer has to do - they develop one part that renders their particular content, then they develop another part that puts a standard UI around the content. – Micheal Johnson Nov 21 '17 at 21:13
  • @Michael Johnson: HTML5 *is* a standard toolkit. A browser is not just a content application, it's an application platform. In fact, it's probably *the* most successful cross platform UI toolkit, and it's probably the only one that actually has a written, vendor neutral standard spec, something that other cross platform toolkits could only ever dream of. Why would they be using what would be, from their perspective, *an inferior UI toolkit*. – Lie Ryan Nov 22 '17 at 16:17
  • @MichaelJohnson: Firefox uses XUL toolkit, which is an in-house cross platform toolkit. While Firefox do integrate with GTK so it can adapt to GTK themes for better integration with the look and feel of the system (which is one thing that Chrome is lacking on), it doesn't really use GTK. – Lie Ryan Nov 22 '17 at 16:23

7 Answers7

153

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.

Hector
  • 10,893
  • 3
  • 41
  • 44
  • 5
    Indeed, 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. – vsz Nov 17 '17 at 12:33
  • @vsz - or just patch out the certificate checks and MitM HTTPS connections. – Hector Nov 17 '17 at 12:38
  • 3
    What if the browser contains malicious code? – Worse_Username Nov 17 '17 at 15:50
  • 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. – Hector Nov 17 '17 at 16:10
  • 2
    @Hector what if they only control a part of the browser? – Worse_Username Nov 17 '17 at 17:03
  • 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. – Hector Nov 17 '17 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. – Carey Gregory Nov 17 '17 at 23:39
  • 2
    @CareyGregory - they do exist. Especially where the application is split into separate processes that run on separate machines - for example gaining control of the database server but not the top level application. But it's rare especially in the context of a browser. – Hector Nov 17 '17 at 23:56
  • 2
    @Hector Okay, sure, if it's a distributed system with apps running on other machines that's different, but someone who's gained control of one app can probably control all apps at the same privilege level and user space on that machine. – Carey Gregory Nov 18 '17 at 00:19
  • @CareyGregory - see my comment above where I said exactly that. Since you stated you couldn't see any scenario I felt it may be beneficial to suggest otherwise. Worth noting you could achieve similar by splitting processing between sandboxed processes on the same machine. – Hector Nov 18 '17 at 00:23
  • One could imagine a browser coded in a radically paranoid fashion, where it not only split into different processes but also aggressively drops privileges in each of them (for example, using a mix of BDS jails and `pledge(2)` on OpenBSD, or namespaces and other modern isolation technologies on Linux). The most vulnerable parts of the browser (the ones acting based on untrusted data from the internet) can be completely neutered to the point where if compromised, they could do almost nothing as the user. Hypothetically interesting, though I think it does not change the answer. – mtraceur Nov 20 '17 at 09:02
  • If I register a protocol handler called "chrome", going to `chrome://settings` opens that application. However, Chrome itself does not use the protocol handler from Windows Registry to open that page, so this won't work from inside Chrome – Thomas Weller Nov 20 '17 at 16:15
  • This doesn't answer the question directly. I can think what you wanted to say, but you didn't write it down. So once again: Why does Chrome say the settings page is secure? – Christian Strempfer Nov 22 '17 at 18:51
  • @ChristianStrempfer - whilst you are technically correct that I didn't answer it you have asked a different question to OP. I view my answer as indirectly answering the question so won't edit it. The answer is they don't have to do anything - they know it is secure because they control every aspect of it. – Hector Nov 23 '17 at 19:08
91

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.

David Richerby
  • 1,636
  • 12
  • 13
  • 10
    Well, I'm sure it's loaded over something, like the OS IO :b – Michael Pittino Nov 20 '17 at 03:05
  • "even though it doesn't come from the web" Don't part of the user settings in Chrome come from your profile so they're synced with all your other devices? I suppose those are stored and loaded from the web. – Mast Nov 20 '17 at 11:02
  • 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. – David Richerby Nov 20 '17 at 11:05
  • 2
    @MichaelPittino, it's not loaded over something any more than your desktop background is. – Paul Draper Nov 20 '17 at 14:46
  • 2
    @PaulDraper Which should also be loaded over OS IO, right? :P – Michael Pittino Nov 20 '17 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. – Peteris Nov 22 '17 at 10:59
37

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.

Kallmanation
  • 1,736
  • 1
  • 8
  • 10
  • 4
    The 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. – Nzall Nov 20 '17 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... – Kallmanation Nov 20 '17 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. – O. R. Mapper Nov 22 '17 at 07:19
30

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

(Mozilla Firefox)

Google Chrome

(Google Chrome)

Arminius
  • 43,922
  • 13
  • 140
  • 136
6

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.

Harper - Reinstate Monica
  • 3,101
  • 10
  • 17
5

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.

Joe
  • 2,734
  • 2
  • 12
  • 22
4

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).

Nate D
  • 191
  • 2
  • 2
  • 8