Looking at cryptography in a place that is absolutely fine but satisfies no meaningful threat model whatsoever and deciding that the correct terminology is "emotional support crypto"

"Is that encryption load bearing?"
"No, it's emotional support cryptography"

@mjg59 I've seen a lot of "performative cryptography"; like an messenger that uses strong end-to-end encryption but ... both ends are a proprietary app owned by a bad actor corporation ...

@yojimbo @mjg59 relatedly, and worse: any form of web based crypto. or rather, "crypto where you're served an unauditable application every page load"

at least it's possible to audit $CORP e2ee apks after the fact.

(now is the v1.2.3.4 they were running the same binary as the v.1.2.3.4 that others have archived? open question :) not one limited to bad actor corps though. )

@mjg59 personally, rather have crpytography where none is needed instead of not having cryptography where some is needed

@16af93 Unless the presence of that cryptography leaves you feeling safe and warm when you really shouldn't be

@mjg59 I’ve been trolling at work for years with this sticker.

I had to do some digging to find the link since the URLs in my receipt have gone 404 in the meantime, but here’s where I bought it from.

https://www.etsy.com/uk/listing/1756628420/encrypted-at-rest-sticker

@mike
@mjg59 I feel like this needs to be a tombstone-shaped sticker.

Or an actual tombstone.

@dymaxion @mike @mjg59 RIE Rest In Encryption

@mjg59 “who are you emotionally supporting?”
“oh, well, the web browser. you see the connection is already encrypted over WireGuard but poor little firefox will not let us use many features unless we add extra TLS”

@sodiboo @mjg59 tbh set up right it’s not hard to both have working internal tls with no cert store shenanigans and also HSTS preloaded on the site

@charlotte @mjg59 yes. it’s not hard . but it’s unnecessary and satisfies no meaningful threat model (the connection is already authenticated and private)

@sodiboo @mjg59 you know there’s transport encryption, the browser doesn’t know that and it simplifies a lot of checks if you simply assume that the channel is unencrypted

@sodiboo @mjg59 hey so fun fact, private networks aren’t always particularly private and also aren’t free of attackers necessarily

you could be like my previous ISP who assigned private range IPs to cgnat devices with literally 0 firewalling

@charlotte @mjg59 sure, they’re not always. but a peer-authenticated wireguard connection is pretty private.

it simplifies a lot of checks if you simply assume that the channel is unencrypted

absolutely! hence, emotional support cryptography. it’s absolutely fine, but satisfies no meaningful threat model.

@sodiboo @mjg59 emotional support cryptography would be adding application layer cryptography in javacript over https for example

tls over wireguard is technically superfluous but “https everywhere” in almost all cases is a good idea

it’s like how when configuring an internal service you would only have it listen on an internal ip (not ::) and not unblock the port in the firewall. one of these is technically superfluous but it’s good to have both

@sodiboo @mjg59 also wireguard authentication is meaningfully different from tls authentication

wireguard authentication says that the peer machine holds a specific key. unless you do stuff like proxying and the like you know that traffic originating from a specific ip comes from a host holding a specific key (which often is stored in plain text on the disk)

tls authentication on the other hand says that the peer has access to a specific application-specific key that belongs to a specific user or service

@mjg59 @sodiboo a simple example imagine family computer A that connects to wireguard-protected resource on server B

using just wireguard authentication all users on the machine could access the service

using tls authentication this could be scoped to anyone with a specific certificate (which could be stored on a physical key and pin-protected)

using application authentication could be scoped to anyone with a specific password or passkey

@charlotte @mjg59 hm. sure. there’s a difference here.

in my scenario, i’m imagining internal communication between devices i own. i have a wireguard subnet there. for all intents and purposes, they are all as trustworthy as localhost. if somehow the application running is not what i expect, and i communicate with it under a false sense of security, then the target machine categorically contains malware and it would have to be either in (1) my service manager (root privileges, pid1 nonetheless), (2) a service with the ambient capability to listen on ports 80,443 (only my reverse proxy; the component that would’ve handled TLS anyways), or (3) some other method that grants privilege escalation enough to listen on restricted ports, aka root access.
in all three cases, i’m fucked and TLS wouldn’t have saved anything.

however, i might still use emotional support TLS just to make the browser shut up and not refuse based on HSTS or whatever else. again, i’m not arguing that it’s useless or a bad idea or that it shouldn’t be done. the cryptography is fine to apply here. but it certainly does not satisfy a threat model. (you do remark that on a multi-tenant scenario, it could be meaningful. i don’t dispute that. but my base assumption is “the connection is intrinsically authenticated and private” which is not the case in the multi-tenant model)

@sodiboo @mjg59 again, it’s not emotional support cryptography. it’s part of the https protocol

@charlotte @mjg59 security is already there! https is strictly unnecessary! it’s just to keep the browser happy! how is it not emotional support cryptography!

@sodiboo @mjg59 like you constructed an environment where the threat model of it happens to not apply. congrats. almost nothing else is like that. adding exceptions to detect if we are on wireguard or sth to determine whether secure origin restrictions should apply or not adds a whole lot of additional complexity which didn’t exist before. this itself increases the risk that an unencrypted communication gets exposed

@mjg59 @sodiboo the browser sees an unencrypted channel, perhaps with lower-than-usual mtu, and low-mtu unencrypted channels do exist

@charlotte @mjg59

adding exceptions to detect if we are on wireguard or sth to determine whether secure origin restrictions should apply or not adds a whole lot of additional complexity which didn’t exist before. this itself increases the risk that an unencrypted communication gets exposed

yes. i agree? i’m not arguing against TLS-on-WireGuard. i feel like you repeatedly ignored me saying explicitly “i’m not saying it should not be done”. i certainly didn’t say the browser should care about this use case. i agree. in the browser, enforcing HTTPS makes sense. but when you zoom out, it’s sometimes completely redundant.

you constructed an environment where the threat model of it happens to not apply.

that’s what emotional support cryptography is?? when applying cryptography in an environment where it does not satisfy a threat model?? did we read a different root post?? sometimes for “no reason” but i brought up the main example where there is still a good reason to need to do this, even though it feels completely redundant (and it is)?

@mjg59 @sodiboo like this is essentially the same argument for why every website should have https

by removing the possibility of having an unencrypted channel, you also remove the possibility that sensitive information is transferred over the wire unencrypted.

The threat model is “exposing sensitive information unencrypted over the wire” which might be met by the transport used, but probably is not

@sodiboo @mjg59 you have repeatedly been saying that it’s redundant and therefore purely decorative

i am saying that https everywhere solves a different threat model which your network by sheer chance is not affected by

@sodiboo @mjg59 @charlotte it happens to be redundant in your specific setup, but this doesn't make it "emotional support"?

@IngaLovinde @mjg59 @charlotte i feel like it does?

like, yes, HTTPS is not emotional support cryptography in general. i agree with this. i didn’t claim it was.

but if i’m deploying a network service on a known-trustworthy interface (such as the loopback interface, or over wireguard to an equally or more trusted machine (trusted as in more authoritative over this service)), i think it feels very unnecessary that i should need to bother with TLS? like. the security of this system as a whole is no weaker if i just don’t do HTTPS. i know that communication is always trustworthy.

and yet, i may still choose to do HTTPS for two reasons:

• it will make the browser happy and let me use certain features
• it will make the end user happy because the browser doesn’t tell them “insecure site!” (somewhat less useful in my scenario, because i’m the only user/client. but the same threat analysis mostly holds for mutually distrusting clients)

it will not:

• improve the security in any meaningful way (the only way for the system to fail is in exactly the same spot that TLS would’ve failed, in exactly the same way)

how is this NOT “emotional support”?? the only purpose is to trick involved parties into thinking it’s secure (which it is, but not because of the action that tricks them into believing it).

what is emotional support cryptography according to you two, if not something just like this??? it’s an entirely reasonable use of cryptography that provides no actual security benefit. (notably, this is mostly orthogonal to a browser enforcing HTTPS everywhere. one might still do this even if the browser does not strictly require it).
in particular, i’m assuming that “emotional support cryptography” is NOT a synonym of “security theater” (which i’m currently thinking of as unreasonable measures intended to trick you into thinking a system is protected against a threat, when it actually isn’t, or when that security cannot be verified)

it happens to be redundant in your specific setup

yes, exactly! a threat model is only really relevant to a specific system. you cannot meaningfully protect all systems everywhere from a given threat. you need to make non-universal assumptions.

@sodiboo @IngaLovinde @mjg59 the browser’s threat model is “the transport is unsafe and can be intercepted and read out and maybe even modified” and localhost traffic is the sole exception that you can know as a browser. there is no way for a browser to determine whether a path has some other encryption applied, an even if it were possible whether it could be intercepted by someone unauthorized. specific niche setups that do not apply to most web access for most users do not get considered because you cannot safely assume that any non-localhost traffic is encrypted

@IngaLovinde @mjg59 @charlotte

what is emotional support cryptography according to you two, if not something just like this???

from charlotte, a few posts up:

emotional support cryptography would be adding application layer cryptography in javacript over https for example

i feel like this is isomorphic to my example! the implication here is that both layers of encryption are done with keys held by the same entity / same machine. (which i made explicit in my example). but without that implied assumption, i don’t think this is redundant at all in general. i can easily think of a messenger, where your packets to the server are encrypted in transit with HTTPS/TLS, and your actual messages are further encrypted at the application layer with keys held by other users of the service. i.e. end-to-end message encryption is an example of what you described, in my opinion.

@sodiboo @IngaLovinde @mjg59 the particular threat model on the server side is different: you know as the admin that the transport is encrypted. you can safely make the assumption that all traffic from wireguard peer ips is from an authorized host, as such your threat model would more be compromise of the peer and not that the network can be spied out by a man in the middle

but you then connect the two threat models together, the stronger one wins by default

you are of course free to not use a web browser (or modify it to meet your weaker threat model!) but the web browser threat model being stronger doesn’t make it emotional support cryptography

@IngaLovinde @mjg59 @sodiboo

also as a related question: should a browser consider the gateway ip on an encrypted wifi network to be a secure origin?

@charlotte @IngaLovinde @mjg59 i’m explicitly not talking about the threat model of HTTPS in general or of the browser in general.

also, notably, most browsers will not refuse to contact HTTP services? and most web services don’t require the browser features locked behind a secure context? for all intents and purposes, HTTPS is entirely optional. the browser does not enforce HTTPS in general. yet i might still do HTTPS in the described scenario, for the sole purpose of convincing involved parties that the secure transport is actually secure. even though it’s not necessary, and even though it doesn’t protect against a threat.

i feel like you are arguing that a Different Security Measure protects against a Different Threat. and i agree with your claim but it’s just . Not what i was talking about. ??? even though the same cryptographic methods happen to be involved in both contexts.

@sodiboo @IngaLovinde @mjg59 browsers don’t fully prevent access to http websites that is true

they do offer ways to block http or mixed access, they restrict features on insecure origin, they are also either optionally or unconditionally redirecting to HTTPS. Browsers warn users about entering personal details on insecure pages, about even opening them (not usually by default). personally i think the restrictions do not go far enough but that’s where pragmatism throws a wrench into things

@sodiboo @IngaLovinde @mjg59

Web browsers are built around their own threat model, if you need something different you need to look elsewhere. that doesn’t make it “emotional support crypto” ever

hell if you encrypt your transport traffic and nobody sniffs it, isn’t that also basically unnecessary in that regard?

or is it just a problem when the protections against threat model A overlap the encrypted transport that you have very unexpectedly applied to a very small amount of destinations?

@charlotte @IngaLovinde @mjg59 no. nor would i. because the gateway IP is not guaranteed to persistently refer to that same host. (e.g. if you switch wifi networks, the exact same page with the same URL can be an entirely different actor, without the server being compromised in any way, shape, or form)

i also don’t think my browser should consider my wireguard subnet a secure context (because, as you say, it cannot know that it has the relevant properties). but i consider it secure because i know that even on a malicious physical wifi network, my wireguard interface will still receive those packets (and, worst case, a denial of service attack can force them to be dropped, but not intercepted).

however, i have seen routers with publicly qualified DNS names. those might be eligible for secure contexts. but again, the browser has no way to verify that without a TLS certificate. (which publicly named gateways generally present; this is the reason they have a public DNS name)

i think that encrypted wifi gateway and my wireguard subnet should maybe be considered a potentially trustworthy origin. that is, on the same level as localhost. i don’t see an inherent problem with this (on localhost, the same host, esp. ports >1024, might also change identity without warning and without an attack per se). but i agree with you that it’s impossible for a browser to actually detect this for a given network. so the browser should still consider them untrusted without TLS. but i can safely consider them “potentially trustworthy”, because i have more context. (to my understanding, the only thing “potentially trustworthy” really means is that the connection is not being eavesdropped on; in particular it is not authenticated (as is required for “secure” status), so you don’t know who you’re talking to (or that they’re honest about their identity), but you do know that you’re talking securely to them, and there is no third party passively listening. see also: optimistic encryption).

@IngaLovinde @mjg59 @sodiboo basically: you encrypt your traffic because you can’t prove that someone could be sniffing it

browsers encrypt their traffic because they also can’t prove that someone could be sniffing it

the threat model is kind of very similar, it’s just that in rare circumstances they might overlap

@IngaLovinde @mjg59 @charlotte

i don’t think my browser should consider my wireguard subnet a secure context. but i consider it secure

i think this is critical: i have a different threat model than the browser. in some sense, my threat model is more “correct”, because it analyses a real specific deployed system and not abstractly all systems.

so i don’t agree that i need to “combine” the browser’s threat model with that of the server. the browser’s threat model (i.e. its requirements for a “secure origin”) is just Different from “reality” and what’s “actually secure” (i.e. what i consider secure).
and that’s okay, i think?

and i think under this real world analysis, it still feels appropriate to call redundant cryptography “for emotional support”. the browser is right to “want” TLS always. the browser is right to complain that there’s no TLS, even when the underlying transport is actually secure (confidential + authenticated). but whether i actually give my browser TLS or not for that connection doesn’t actually affect the “real” threat model. it only affects the browser’s “abstract” threat model, which is based on less assumptions than what i can safely make about my system.

and i think crucially, if you’re looking at the browser’s level of abstraction, “TLS over WireGuard” is not at all a thing that exists. WireGuard is not standardized or known to the browser; the secure tunnel is transparent to the browser. so indeed, from its perspective, “HTTPS” is a good thing.

but from my perspective, as the only human in my system, i see that it is actually “TLS over WireGuard”

so depending on where you analyze it, the TLS is either loadbearing, or completely redundant. this is, in my opinion, what “emotional support cryptography” must mean. some component can rightfully analyze it as loadbearing, but when the system as a whole is analyzed, it doesn’t actually provide any additional desired security properties.

i conjecture that the browser’s threat model is roughly summarized as such: “the browser must never trust a connection more than the human can”. if i do not trust the confidentiality of a connection, then the browser mustn’t consider that a secure origin. and indeed, that is true of reality. that is how it behaves. this is a good thing. and it doesn’t mean that all my threat analyses should be based on what the browser can determine programmatically. i have more context than the browser. i can make more assumptions about my system. so my threat model wins over the browser’s by definition: the more specific threat model wins, not the “strongest” or “strictest” (but the resulting analysis is also more specific, and not broadly applicable outside of the system whose assumptions were used)