Is there a way to disable certificate verification or do user-defined verification in the browser?

[guest271314]

I'm trying to replicate pion/offline-browser-communication without using Pion. There's a couple lines in the source code https://github.com/pion/offline-browser-communication/blob/master/server.go#L38C1-L40C51 that reads

// Disable DTLS Certificate Verification. Currently we aren't able to use stored certificate in the browser s.DisableCertificateFingerprintVerification(true)

Is there a way to disable certificate verification in the browser, or perform user-defined certificate verification?

[Harald Alvestrand]

Only if you modify the C++ code.

The most relevant line is probably https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/rtc_base/ssl_adapter.h;drc=0bdeb7818cb6248017867b5e7d4e1cba33500dfc;l=45

--
This list falls under the WebRTC Code of Conduct - https://webrtc.org/support/code-of-conduct.
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/00392545-fbd8-4e4f-8dc0-e7809b75fc96n%40googlegroups.com.

[guest271314]

Thanks. Any reason this is not an option in user space? 

Context: 100% local WebRTC communication, between tabs/windows.

[guest271314]

For example, since there's this https://github.com/explainers-by-googlers/verifyTLSServerCertificateForIWA coming out of Google internally, should be possible for WebRTC. 

From intently watching this https://discord.com/channels/1352636971591274548/1352636972614680659/1395749852272525453 I gather the reasoning behing the encryption was the events surrounding the disclosures of Edward Snowden, and the interception tactics used by various entities at hubs and such to gather information.

However, if I'm on my own machine, not reaching the Internet at large, those concerns should be N/A. Unless there is a legitimate concern about those same third-party entities somehow intercepting local signal communications, too; offline.

[guest271314]

Pardon, discord is horrible for citing linking to. I refer to this video by Tim Panton https://archive.fosdem.org/2021/schedule/event/tims_webrtc_history/

[Philipp Hancke]

The WebRTC security model is based on matching the fingerprint of the remote certificate which is why pion hardcodes a "static" one.

That throws the security model out of the window obviously but that is a problem of that pion sample (with way too little discussion of why that is a bad idea)

To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/09a9cc80-6462-4639-9d89-9730c80a54dfn%40googlegroups.com.

[guest271314]

What is the security concern when the usage is 100% local to the same machine?

[Philipp Hancke]

how does the browser that the security requirements do not apply to your use-case?

To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/bc3c955f-0cde-4d90-a04c-157004f0a739n%40googlegroups.com.

[guest271314]

That's my question. 

How are security concerns relevant when I'm using WebRTC Data Channels **completely** locally?

The security model, as I read it, are there to avoid third-party entities from reading the underlying data at hubs in the Internet at large.

My understanding of communication over loopback interface, 127.0.0.1, is that no data is sent over the external network.

So what's the security concern with **local only** peer-to-peer, for my use case tab-to-tab and window-to-window communication?

I'm just not seeing any security concerns at all. Kindly illuminate, in detail, if I'm mistaken.

[Philipp Hancke]

you are tackling this from the wrong angle. To change the current state you must explain why what you want is secure and allowing it does not open up unexpected holes in anyones security model.

To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/234f47f2-62a1-4639-b410-aec8990a4751n%40googlegroups.com.

[guest271314]

I think I did explain why what I'm asking for is secure. 

There's no external networking involved at all.

All of the communication is completely local, over the loopback interface.

I don't see how me using WebRTC Data Channels on my own machine, between tabs or windows in Chromium, can possibly impact anybody elses security model or machines at all.

[Philipp Hancke]

read the "localmess" paper again. Even for tabs, breaking cross-origin models is a problem - if it was not you could use e.g. broadcastchannel to communicate the keys between different tabs using the same page.

To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/6fce71e1-43b7-4b98-8863-d11dc4e1596en%40googlegroups.com.

[guest271314]

I read the localmess paper. Twice. 

Chromium supports WICG File System Access. So that obliterates any concept of "cross-origin" isolation. 

Anybody can write local files and directories to the actual file system, and read those files and directories from any other tab or window, or any other browser for that matter using <input type="file">. 

Even if we're talking about WHATWG File System and the "Origin Private File System", it's possible to read the data stored in the Chromium configuration folder "out of band", from within Chromium, and using applications outside of Chromium, see https://gist.github.com/guest271314/78372b8f3fabb1ecf95d492a028d10dd#file-createreadwritedirectoriesinbrowser-js-L118-L162 


// Helper function for filesystem *development*
// Get directory in origin private file system from Chrome configuration folder.
// fetch() file: protocol with "file://*/*" or "<all_urls>" in "host_permissions"
// in browser extension manifest.json
async function parseChromeDefaultFileSystem(path) {
try {
const set = new Set([
32, 45, 46, 47, 48, 49, 50, 51, 52, 53,
54, 55, 56, 57, 58, 64, 65, 66, 67, 68,
69, 70, 71, 72, 73, 74, 75, 76, 77, 78,
79, 80, 81, 82, 83, 84, 85, 86, 87, 88,
89, 90, 95, 97, 98, 99, 100, 101, 102,
103, 104, 105, 106, 107, 108, 109, 110,
111, 112, 113, 114, 115, 116, 117, 118,
119, 120, 121, 122,
]);
const request = await fetch(path);
const text = (await request.text()).replace(/./g, (s) => set.has(s.codePointAt()) ? s : "");
const files = [
...new Set(
text.match(
/00000\d+[A-Za-z-_.0-9\s]+\.crswap/g,
),
),
].map((s) => {
const dir = [...new Set(text.slice(0, text.indexOf(s)).match(/(?<=[@\s]|CHILD_OF:0:)([\w-_])+(?=Ux)/g).map((d) =>
d.split(/\d+|D140/)
))].flat().pop();
const re = /00000[\d\s]+|\.crswap/g;
const [key] = s.match(re);
return ({
[key]: s.replace(re, ""),
dir
})
});
return {
name: files[0].dir,
files
}
} catch (e) {
console.error(e);
}
}
// let paths = await parseChromeDefaultFileSystem("file:///home/user/.config/chromium/Default/File\ System/021/t/Paths/000003.log");
// console.log(JSON.stringify(paths, null, 2));

Further, all browsers support clipboard writing and reading. Clipboard data is stored at the system level. So we can already communicate across origins, and across browsers. For example, when I was asking for speakers to be captured by getUserMedia() and Media Capture and Stream folks said "No" in so many words, I created this to capture speakers on Firefox Nightly and stream audio to Chromium https://gist.github.com/guest271314/04a539c00926e15905b86d05138c113c. I just re-tested today. Still works.

We can already communicate between arbitrary tabs and windows, and even browers. By exchanging SDP. Here's communicating between any arbitrary tab or window and an Isolated Web App https://github.com/guest271314/sockets/tree/fetch-webrtc.

I always keep a few ways to break out of alleges sandboxes in my back pockets so if you folks can manage to close one loophole, I can use 2 or 3 other loopholes.

So the concept of cross-origin isolation is laudable in theory. Simply doesn't work in practice. There's too many ways to get around the *idea* with one of the many Web API's that spring out. 

I try to disclose these things. Actually, I really just try to ask first for **user-defined** features. You folks say "No". Then I go about breaking your gear until I achieve my aims. 

To me it makes sense for stakeholders to, perhaps, listen to developers in the field when they make feature requests, so they don't have to break your ideas and API's that are written out on paper, in reality. 

I'm not malicious. I hack these browsers for sport. 

Stakeholders and maintainers don't seem to listen. Perhaps become rigid, in their own circles. So, developers in the field simply get around "No" by making their use cases so, by any means necessary.

In summary, the *idea* of cross-origin isolation in these browsers is just an idea. In practice, it's simply IMPOSSIBLE. There's just too many ways for motivated, and non-malicious users to get around the *concept* on paper of "cross-origin" isolation.

[guest271314]

What *should* really happen, when ANYBODY makes claims about this or that technology or API being "cross-origin isolated", is for the stakeholders and maintainers to immediately contact a few dozen developers and hackers OUTSIDE OF YOUR GROUP to try to break your gear, and VERIFY your **CLAIMS**. I don't see that really happening much. Maybe you folks enlist Igalia for some stuff, but you don't really outsource to people who are not interested in your claims being true or not.

In other words, none of you, in these community groups, nor at the specification level, are really actively trying to break your own gear. And it has been mathematically proven, over 100 years ago, that you can't prove the vercity of your own claims. Godel put Russel's volumes to bed with a couple lines, that have not been refuted or repudiated

1. If a (logical or axiomatic formal) system is consistent, it cannot be complete.
2. The consistency of axioms cannot be proved within their own system.

- Kurt Gödel, Incompleteness Theorem, On Formally Undecidable Propositions
of Principia Mathematica and Related Systems

[Harald Alvestrand]

Security, of course. It's not nice to permit any webpage to make any connection to anywhere without a reasonable assurance that both ends actually want the connection to be established, and that the other entity is reasonably certain to be the one they desired to connect to.

As evidenced by localmess, this also applies to local-to-local connections. If you have full control of your environment, you are free to compile your own browser for that environment.

To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/94a3a15e-4614-4538-89be-2893d174b4d3n%40googlegroups.com.

[guest271314]

With all due respect, people just throw the term "security" around as if it actually exists on the Web. 

The Web was not designed with "security" in mind, at all. 

Only when folks started peddling their Bennie Babies and such did the idea of, oh well, let's try to throw in some stuff after the fact onto this thing we got.

I already demonstrated multiple ways above that absolutely annihilate any claim that there is any alleged cross-origin communication on the Web. 

Ironically, WebRTC is one go-to way to get around any alleged cross-orign "security" model in this inheretly *insecure* natural world. 

I'm on my machine. I'm just trying to communicate using hardcoded addresses on localhost. And skip a step in the SDP exchange mechanism.

I think it's far past time that specification authors and maintainers top pretending like there's really such a thing as "security" in these Web applications. There ain't. 

If I'm looking for examples of corporations harvesting user data, again, with all due respect, Google is not excluded from that criteria. Web Speech API alone is horrendous. 

Alphabet, by way of Google could ship TTS and STT capabilities in the browser today if they wanted to. Instead Google is still harvesting user PII, and trying to sell something over the cloud, even though the debt to cah on hand shows Google ain't in debt. Don't point fingers at Facebook/Meta when Chrome is recording users voices and sending those voices to Google servers to do who knows what with - yet covering any open surafce available with "AI" advertising.