4 ms·
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
by crazygringo 9mo ago
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.
- wolfi1 9mo agoas 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
- crazygringo 9mo agoWhat 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.
- sharperguy 9mo agoThey 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.
- crazygringo 9mo agoRight. 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.
- awesome_dude 9mo agoWorst 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)
- deleted 9mo ago[deleted]
- majkinetor 9mo agoIts 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.
- cryptonector 9mo agoYou _think_ it's anonymous.
- danaris 9mo agoWhat 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.
- crazygringo 9mo agoRight. 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.
- danaris 9mo agoBut 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.
- crazygringo 9mo agoWhich accomplishes what? The hash isn't used for anything else or tied to anything else publicly.
- danaris 9mo agoThey can see that someone opened a tracking pixel from $BANK (or wherever), and, with your other activity, potentially tie that to you.
- cryptonector 9mo agoYes 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.
- chowells 9mo agoThe article addresses this, actually. Fetching any unsecured content is an attack vector. https://danq.me/2026/01/28/hsbc-dont-understand-email/#footnote-27343-7 https://danq.me/2026/01/28/hsbc-dont-understand-email/#footn...
- crazygringo 9mo agoIn 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.
- matthewmacleod 9mo agoThis 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.
- deleted 9mo ago[deleted]
- crazygringo 9mo agoIf 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.
- samrus 9mo agoThe 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
- cess11 9mo agoThe 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.
- majkinetor 9mo agoI 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.
- jdsnape 9mo agoHTTPS 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