Hacker News Reader

Comment by jackfranklyn | Hacker News Reader

[flagged]

> But the reality is most banks treat their digital infrastructure like legacy plumbing - it works well enough that nobody wants to risk touching it.

They don't seem to have nearly the same concern for their online banking web UIs, though. Or even the UIs presented on screen at ATMs.

Not that it justifies arbitrary UI updates but that has a different risk profile. It would be a potentially existential crisis for a bank to (for example) push an update to backend systems that credits one account without debiting another, especially at scale. In comparison, changing the graphical interface of clients which connect to those systems has a rather isolated blast radius.

"Someone had to actively choose to serve content over http in 2026."

To be fair, people actively choose to do this every day

For example, millions of people actively choose to do this for HTTP-01 ACME challenges

https://www.ietf.org/rfc/rfc8555.txt

https://letsencrypt.org/docs/challenge-types/

Certificate authorities also actively choose to do this for

1. TLS Certificates

For example, http://www.ssl.com/repository/SSLcom-RootCA-ECC-384-R1.crt

2. TLS Certifcate Revocation Lists (CRLs)

For example, http://crls.ssl.com/ssl.com-ecc-RootCA.crl

3. Online TLS Certificate Status Protocol (OCSP) responses

For example, http://ocsps.ssl.com

NB. If the statement was more specific, something like, "HSBC chose to use HTTP for return receipts in 2026" then I would have no reason to comment. Instead the statement suggests HTTP is no longer a useful nor appropriate choice for _anyone_. That of course is false, as shown above

I choose to serve my blog over HTTP, because we need no intermediaries to publish content on the Internet.

Just your ISP, their ISP, your hosting provider (if applicable) and the browser vendor.

Adding in an optional HTTPS there would not greatly increase the amount of intermediaries, though I by no means argue that it matters.

It brings in one central intermediary used by most of the internet, converting a decentralised system to centralised.

For end users of websites ("users") one problem with so-called "WebPKI", as this "WebPKI" is currently implemented, is

(a) it forcefully "delegates" trust to third parties, i.e., commercial CAs

(b) these CAs, for a fee, are happy to trust sites that the user would not trust if given the choice of which sites to trust, e.g., ad servers, tracking servers, etc.

(d) popular browsers distrust the user's freely-generated CA certificates

The efforts of the user who wants to sign a small number of certificates from sites that he trusts are deliberately hindered by (d). For example, browser warnings, interstitials, TLS failures. The user is effectively discouraged perhaps even prevented from trusting himself, i.e., his own CA, while being forced to trust pre-installed third party commercial CAs

One might reason this problem could be avoided by not using popular browsers. However, website owners, and today, "Content Delivery Networks" (CDNs), attempt to coerce or force users accessing websites to use popular browsers. The CDNs terminate TLS connections and substitute their own server certificates . These certificates are signed by CAs approved by the browser vendor. This produces no browser warnings, interstitials, or TLS failures

However if the user terminates TLS connections and substitutes her own free certificate signed by her own free CA,^2 then this will trigger browser warnings, insterstitials and/or TLS failures. The practice of the user trusting herself more than third parties is deliberately hindered

From this state of affairs, one might conclude that TLS termination is acceptable under this "WebPKI" so long as the CA is approved by the browser vendor and the user is not the one doing the termination

These pre-installed certificates in (c) are also distributed by a popular browser vendor as a "bundle" for installation in operating systems, non-browser software, etc.

In other words, users get these CA certificates not from the CA but from another third party, i.e., a browser vendor

But it's also possible to get the CA certificates directly from the CAs

This can be done over HTTP (cf. HTTPS)

I do this using a loopback bound TLS forward proxy. I use TLS failures as an additional way to block undesired connections, e.g., to Google servers (another form of so-called "de-Googling")

The proxy performs _many_ different functions for me, allowing far more control and versatility than a popular browser. Plus I can modify and compile the proxy myself even on underpowered computers; it's only several MB. Whereas compilation of a popular browser is impractical by comparison. Compiling a so-called "modern" browser consumes too much time, CPU, RAM and storage space

One function is sending all HTTP requests over TLS, so, e.g., an http:// URL as in this story about HSBC would be sent as HTTPS^3

This applies to all software sending HTTP requests on the computer, not only browsers

I have a file that lists sites for which I do not want to go over HTTPS. This file is loaded into the proxy's memory and these sites will be forwarded by the proxy without using HTTPS. This is a short list but an important one

I use rinetd and DNS to send TCP and HTTP traffic to the proxy as opposed using the firewall. As such it's still possible to reach non-HTTPS sites via IP address, even in popular browsers

If HSBC used IP addresses rather than a domain name, then this could bypass the proxy

> “Every bank formats their statements differently…”

In my experience with bank data, on the downstream side, banking data is available in the OFX specification, which is a consistent transaction data format. Unfortunately, memo’s do get truncated to different char lengths by different banks, even though the specification allows 255 characters. AMEX, amazingly, switches NAME and MEMO properties. It's a dog breakfast of compliance, but there is a standard.

https://en.wikipedia.org/wiki/Open_Financial_Exchange

https://www.financialdataexchange.org/FDX/FDX/About/About-FD...

How do you get OFX data from your bank?

Most bank feeds have option for QBO or QFX file export. The export is a text file. Open it with a text editor and the first three lines are:

    OFXHEADER:100
    DATA:OFXSGML
    VERSION:102

Does HTTP really matter in this particular case though?

HTTPS still typically exchanges the Server Name Identification. So you know somebody is talking to HSBC. And the rest of the URL is just an anonymized tracking ID. So I'm having a hard time seeing what the threat is this particular instance.

Yes it matters. First, there can be much much more metadata in the URI local part than just in the SNI -- just because it looks anonymized doesn't mean that it is. Second, ESNI is a thing and it's going to get more deployment. Third, DNS queries for ESNI can go over HTTPS/TLS/QUIC.

The author put some text in base64 in the URL:s, perhaps the original had information encoded in such a way that might leak something interesting.

"Not the real HSBC", and "Also not real HSBC" respectively.

I don't think it matters at all.

HTTPS doesn't encrypt query parameters. Content of the image itself is irrelevant, as its only purpose is to get request URL into the server logs.

HTTPS does encrypt query parameters, all of the HTTP request goes inside the encrypted session.

The only thing outside is the hostname, if the connection is not using the latest versions

The article addresses this, actually. Fetching any unsecured content is an attack vector. https://danq.me/2026/01/28/hsbc-dont-understand-email/#footn...

In this particular case, injecting content into the image to make someone read a false message doesn't seem possible. The pixel <img> tag has width and height set to one. This overrides whatever the image size is. No altered message will be readable.

This is true up until the point that someone finds a security issue with an image parser that’s present in a browser engine, and suddenly you have an RCE.

If you have access to an exploit and want to compromise someone with an image, you'd usually just send it to them directly via e-mail or SMS or AirDrop or whatever, or all of the above. And it'll even work if your image is linked in an email via HTTPS.

Trying to MITM an existing tracker pixel when they're connected to public WiFi sounds like practically the hardest way to do it.

The harder it is to do, the more the targets guard will be down

In this case, sending your malicious image through a fake email might get flagged, or even not opened by someone whos been trained in infosec enough to be suspicious of these things. But a tracking pixel in an email that is verifiably from a trusted entity will be opened no problem. Type of thing that will look pretty slick if you read about it being used

It's incredibly easy to get people to open emails. This isn't asking them to download an attached .zip or .exe file or follow a suspicious link, which is what people are trained against. This is just an embedded image.

as it's a tracking pixel it's personalized, if you are reading your email in the cafeteria with their wifi, potentially everybody in the cafeteria know more about you than they need

What do you mean it's personalized? It's an anonymous identifier token specific only to that email.

Like I said, even with HTTPS everyone in the cafeteria theoretically knows you're connecting to HBSC as well.

So I don't see the difference.

What on earth makes you think it's anonymous?

It's trivial to encode each tracking pixel with a personalized hash of some sort linking it to the intended recipient of that particular email.

This is...just how tracking pixels work.

Right. The hash is anonymous to anyone without access to the internal database of hashes at HSBC. That's how tracking pixels usually work. Sniffing the HTTP connection isn't giving you any way to de-anonymize the recipient. It's a hash, not a long-term identifier.

But if they're sniffing your wifi, they can, at the very least, tie it back to your IP address. Along with all the other traffic from your session—which, if you're not using a VPN (in which case they can't get this anyway), is likely to leak enough to provide several more points of identification.

Which accomplishes what? The hash isn't used for anything else or tied to anything else publicly.

They can see that someone opened a tracking pixel from $BANK (or wherever), and, with your other activity, potentially tie that to you.

You _think_ it's anonymous.

They know that you likely read some email from HSBC and if you happen to read the same one again they will know it was the same one.

Right. But even over HTTPS it's not rocket science to figure out that connecting to www.email1.hsbc.co.uk pretty strongly suggests you've opened an e-mail with an image. And the number of times you request the same URL tells someone... what exactly? Because HTTPS still tells people the number of times you access any URL on a domain.

Worst case scenario is the HTTP pixel request tells attackers that there is a verification chat happening.

HTTPS the attackers know a conversation is happening, but no idea what

But, I personally think the threat is being overblown (I am happy to be corrected though)

Its not only overblown, its totally non-issue.

The main problem seems to be tracking pixel itself to deduce involvement. The suggested approach to send email to confirm email seem better, unless it contains link to login page (as it can be phished). So, the best seems to be that one should send email that explains user how to confirm e-mail by logging manually to the app.

More than likely its a third party service managing the tracking of the email. Serving content over http just requires them to ask HSBC to add a domain entry for their (cName) server. HTTPS would increase the amount of work required.

Reply on news.ycombinator.com