* The attacker managed to issue multiple SSL/TLS certificates via Let’s Encrypt for jabber.ru and xmpp.ru domains since 18 Apr 2023
* The Man-in-the-Middle attack for jabber.ru/xmpp.ru client XMPP traffic decryption confirmed to be in place since at least 21 July 2023 for up to 19 Oct 2023, possibly (not confirmed) since 18 Apr 2023, affected 100% of the connections to XMPP STARTTLS port 5222 (not 5223)
* The attacker failed to reissue TLS certificate and MiTM proxy started to serve expired certificate on port 5222 for jabber.ru domain (Hetzner)
* The MiTM attack stopped shortly after we begun our investigation and network tests on 18 Oct 2023, along with tickets to Hetzner and Linode support team, however passive wiretapping (additional routing hop) is still in place at least on a single Linode server
* Neither servers appear to be hacked
* Both Hetzner and Linode network appear to be reconfigured specifically for this kind of attack for the XMPP service IP addresses
---
Neither that page, nor the page linked from here, mention certificate pinning, maybe because XMPP doesn't support it (I don't know), but if it did, wouldn't that have prevented this kind of attack?
XMPP supports channel binding, which is not mentioned in this post but would have prevented this attack. Unfortunately jabber.ru is running server software from 2016, and that old version doesn't support it.
Pinning is problematic these days, because certificates are short-lived and renewed frequently. Users would be constantly asked to accept new certificates on a monthly basis, and they wouldn't think twice about clicking 'Accept' on an attacker's certificate then.
Channel binding works regardless of the certificate, and ensures the TLS stream is terminated by the entity you exepect.
The focus on (lack of) CT/SCT support in XMPP clients puzzles me, because it would not have detected this attack at all, which used valid CT-logged certs from Let's Encrypt. SCT verification would help detect theoretical issuance from another CA if they had a strict CAA record in place (they did not). But even then, channel binding is more privacy-friendly and does not depend on a third party.
Someone was forced to do it, but they didn’t personally agree with it so they eventually made a “mistake” to tip off the target?
There is the plain incompetence explanation: the hosting provider gave control of the operation to the government entity. The underpaid and indifferent government employee did the best they could with their level motivation and skill level.
I mean, I’ve seen the auto renew fail a lot with the certbot. They definitely should have checked it in the renew period to make sure it was working, but I feel for them
>affected 100% of the connections to XMPP STARTTLS port 5222 (not 5223)
Why did they only target the STARTTLS port? On a related note, I would never use the STARTTLS port (opportunistic encryption) if I knew that the server had a regular TLS port...
>I would never use the STARTTLS port (opportunistic encryption) if I knew that the server had a regular TLS port...
That is what XMPP clients tend to do...
These days XMPP servers tend to default to requiring TLS on both 5222 and 5223 (Let's Encrypt has changed everything). Prosody does this for example. It doesn't even support port 5223 by default anymore. Port 5223 was never an official port assignment.
So it is very possible that the MiTM was only done on port 5222 because that was the only port that clients were using.
The MiTM attacker can pass through a command stream without STARTTLS. If they intercepted 5223 they would have to do their own client-side TLS handshake with the attacked server, which would look really obvious to anybody doing TLS fingerprinting on the server: all of a sudden, 100% of their clients have the exact same TLS fingerprint.
Stop outsourcing your PKI to ICANN, folks. Domains are not public keys.
It is pretty simple.
5223 port is called "legacy SSL".
So, because it is legacy, clients would, by default, use 5222 + starttls.
I.e. majority of clients connect with 5222.
Also, I've never understood why they've moved 5223 (regular TLS) into deprecated. It was pretty useful to enable SSL on AWS ELB on this port. Which is not possible with 5222, because it does XML stuff before switching to TLS.
I would speculate it is to not keep 2 ports open or something, was a reason to move it to deprecated. + you can do some cleartext communication before switching to TLS (not like it is that useful).
>The attacker managed to issue multiple SSL/TLS certificates via Let’s Encrypt
This implies that the attacker was able to validate domain ownership of jabber.ru and xmpp.ru by either a) being able to respond to the ACME protocol on domain(s) hosted http OR b) being able to write to a DNS TXT file for the domain(s). This implies that the victim already lost control of their process server and/or their nameserver.
No. Most probably it merely implies someone upstream of them (presumably their hosting provider under compulsion from German law enforcement) intercepted and spoofed their unencrypted, unauthenticated ACME HTTP traffic.
How would you do certificate pinning if you don't control the clients?
My understanding is that certificate pinning is only possible if you control the clients, in which case you can embed which certificates are allowed directly in the client and bypass the whole web PKI.
In a situation with general-purpose clients connecting, how would they know which certificates are meant to be allowed? That's what the web PKI is used for.
Of course, if you do provide your own clients, this just moves the problem further up the chain - in this case the place where customers would download the custom client software would be compromised and a malicious client served instead.
> How would you do certificate pinning if you don't control the clients?
Well you cannot. If you were paranoid, you would perhaps supply a hash through some out-of-band mechanism, which would require manually updating for each new cert.
Obviously most people wouldn't ever want to do that.
Tele communication companies have internal “police groups” (where I am from - I expect it to be the same in Germany) that does nothing but service wiretapping requests from the police. Telcos are required by law to do this.
Them expanding into mtm https wiretapping is a new for me but maybe to be expected …
This list lacks the most obvious one: enable (and ideally enforce) SCRAM-xxxxx-PLUS as the authentication method of choice.
The idea of the PLUS variant is both simple and effective: instead of verifying <user,password> with the help of a salt you are verify <user,password,tls session key>.
That way the authenticating is only valid on a single TLS connection.
Who are the end users of xmpp.ru and jabber.ru? Are they hoping to pick up traffic between Russian soldiers? Spies? I hate mass surveillance as much as the next guy but why target Russian domains specifically?
I can't imagine it is war-related, or at least not in any direct sense, like literally trying to intercept soldiers or spies.
I think the more likely scenario is that someone was to catch carders/botnet operators, since Jabber/XMPP is still very popular amongst people in that scene in Russia; you'll see often see screenshots or logs containing @exploit.in, @jabber.ru, and various other servers pretty much in any Krebs on Security article, for example.
That said, I think mass-surveillance is usually pretty gross regardless of intent.
I don't know what the exact ratio of criminal to non-criminal usage of either server is, but just like how Tor simultaneously has a ton of obviously illegal content mixed with whatever percentage of legitimate use [1], they presumably still do have a fair amount of totally normal conversations going on. And so I'm not an exactly a huge fan of invading privacy in order to spy on random cybercriminals likely far out of your jurisdiction in countries unwilling to extradite in the first place.
And while I understand if Hetzner was forced to comply, unless they wanted to become another Lavabit, as someone who recommends them often, it'll still be a little disappointing, IMO, if it turns out they were aware and allowed or assisted in the MitM attack, because otherwise, I think they're one of the best hosting companies.
Their transparency is great. And I get better uptime, reliability, and support than the overwhelming majority of cloud providers without selling my organs to afford it. And their effort put into turning environmentally-friendly design choices into economically smart choices is commendable.
The "reduce" in reduce > reuse > recycle can be seen in their KISS designs—like the raised, angled roof, allowing natural heat escape rather than loads of HVAC [2]; server chassises that are more bare-minimum structural support and air-shrouds than actual chassises; and stripped-down standard motherboard designs with only the most minimal changes, like 90-degree rotated sockets to allow a single fan to cool the VRM, CPU, and memory [3], rather than a dozen screaming, power-slurping Delta fans for every server.
And their knowledge of "reuse" is evident by their server auctions, where they do Dutch-auction-style rentals of legacy hardware rather than scrapping everything, avoiding spending a load on new hardware while also avoiding the environmental cost associated with manufacturing new everything each generation.
I'd love to be able use them more if only they had dedicated servers outside of Europe.
[1]: "legitimate" is hard to define anyway; one country's journalist is another's "foreign agent", and one country's "freedom fighter" is another's "terrorist".
> I can't imagine it is war-related, or at least not in any direct sense, like literally trying to intercept soldiers or spies.
The Ukrainian military has been using Discord, so it's not totally unimaginable. Are these domains administered by Russians? IMO it would be pretty naive for Russians to be hosting comm servers in NATO datacenters right now. Perhaps related: I interviewed for a job recently where the hiring manager was a Russian immigrant. He was telling me I should go visit St. Petersburg and didn't seem to understand that is not an option at the moment. I was flattered by the suggestion of course and it is a nice reminder that regular people are typically tolerant, but also confused. Do people not understand the severity of the situation or is this behavior of acting like it is business as usual a coping mechanism?
> I can't imagine it is war-related, or at least not in any direct sense, like literally trying to intercept soldiers or spies.
Perhaps a majority of war between technologically developed countries these days occurs on the internet - just because no soldiers or spies are involved in something, that doesn't mean it isn't direct war. Example: propaganda around Russia/Ukraine last year and Israel/Palestine this year
They point out that "CT is optional", but isn't that ultimately a decision by the XMPP clients? What stops them from requiring CT now that browsers effectively do? What trust store would they be relying on that issues certificates that don't work in the browser?
Right, they could do this and this seems like a good idea to me. The problem this require-CT behaviour isn't switched on by default for basically any TLS library, so an XMPP client developer would have to go out of their way to switch this on, and I assume most or all (currently) don't. That can change of course.
How problematic is that in real life? All CAs worth their salt are already publishing all certificates to CT logs because most TLS servers are browsers and most clients are browsers.
Maybe there's a CA somewhere that has opt-in CT logging enabled, but I don't think they're very popular. For example, even the rogue CA certificates were published onto the CT log (because Let's Encrypt does so by default).
I think a CT check shouldn't be a very problematic change in practice, as long as there are reasonable exemptions (i.e. don't require CT for certificates imported into the CA store, allow the user to disable the check, etc.). For server<->server communication things become more difficult, but the entire network would be better off if a major server like ejabberd were to require CT.
Thinking laterally for a moment regarding the big picture here, why do we still rely on data centres.
They made sense in a world of dialup and low speed / high latency broadband. But there are lots of places with high speed fibre and not much latency to the peering points.
And the more we break away from data centres and clouds, the more the internet infrastructure will have to work the way it was designed instead of having to flow through these crazy aggregation points that are both serious points of failure and major security risks.
> They made sense in a world of dialup and low speed / high latency broadband. But there are lots of places with high speed fibre and not much latency to the peering points.
Yes, but then you need backup power, someone to replace disks / hardware if things break, proper security for compliance reasons, cooling, noise. Once you set up all these things you just invented a data center again.
I don't see how getting rid of data centers makes any sense.
Regular domestic connections often block ports (especially email). In many countries, ISPs won't sell you a static IP (your dynamic address might not change ever, but you don't control rDNS records).
These kind of measures force people to move onto a rented server instead. Often ISPs rent servers themselves. The conflict of interest here is hard to ignore: if ISPs make it easy and convenient to host from home, their business of renting servers suffers.
All the people working in the datacenter have that level of physical access.
Unless they are very closely supervised they can do a lot of damage without anybody being the wiser until they get caught. I've been in (nominally very secure) DCs on behalf of customers and I've seen:
- unlocked racks
- doors open
- temporary network cables and keyboards, monitors and mice attached to running systems
- systems logged in left unattended
- floor panels raised up and left open unattended exposing cabling
- meet-me rooms with interfaces exposed (gear in racks without doors)
DC personnel tends to trust each other, and they probably shouldn't. But it's hard to be part of a closely knit crew for a long time without getting into a 'get stuff done' mode where protocol and rules are there in principle but less so in practice because it is seen as an efficiency penalty. It's another instance of the 'normalization of deviation' phenomenon.
The organization conducting the MitM likely has physical access to the machine already. The original post indicates the link on the network interface went down for 19 seconds, indicating a device was placed in front of the server.
Assuming this was done at the government's request, I assume Hetzner is more than willing to comply with a court order mandating they allow them to monitor and physically size a machine.
And outside of nation-state requests, even ignoring the fact that someone could probably pay-off an employee, I think ease would depend a lot on the datacenter and target; judging by the awesome and hilarious story behind the Fremont Cabal accidentally becoming an internet exchange by essentially having some dude barely secretly slipping unauthorized cables into the raceways [1], I figure there are a lot of places where if your target is simply renting a couple rack units or single rack rather than an entire locked cage, you can probably get physical access by doing the same.
Also, a lot of Deviant Ollam's stories about industrial security and the dozens of ways he's broken into utility companies, server rooms, etc — mostly just by being confident, looking the part, bad doors [2], and badge cloning [3] — don't give me a ton of confidence that someone with skill couldn't feasibly either get direct access to servers they shouldn't, or at the very least, access to an important part of the supply chain for their target.
And speaking of supply chain, my processor died recently, so I ordered a brand-new in box replacement Ryzen, and when it arrived last night, out of curiosity, I wanted to see if I could get the CPU out of the box without breaking the tamper-evident authenticity seal...
... and about fifteen minutes later, after borrowing a syringe and hypodermic needle from my mom, a little bit of isopropyl alcohol, a blade from my safety razor, and a quick look at a video from LockPickingLawyer [4] and a couple from datagram at DEFCON's Tamper-Evident Village [5][6], I had the CPU out, put my old one for now, and re-applied the sticker with no visible damage to the box or seal.
All I had to do was tip it upside down at about 90-degrees, douse a little bit of the alcohol under the top of the seal, let gravity do most of the work, and then carefully lift the seal with the razor. After that, I just lightly squeezed the box to make the front tab come as forward as possible, and then carefully pushed the ear flaps down to prevent tearing, and then I was in.
I've seen others demonstrate it on older AMD boxes that had flexible cardboard in-place of the cooler, allowing them to pull the cardboard to make enough room for tools to get out the CPU without even touching the seal [7]. But in my case, it was a newer box with hard plastic inside where the cooler would've been, so that's why I went for the seal instead.
No surprise to me now that counterfeiting is rampant on Amazon, with people returning the box after putting in either random junk, dead Athlons covered by a counterfeit serial-matching IHS, or the cheapest socket-compatible CPU after deluding both and swapping the IHS.
I figure with a bit of practice and better tools, like Teflon spudgers and syringes, it'd be significantly easier to get past 99% of tamper-resistant/tamper-evident seals and into boxes you're not supposed to be without risking damage, and then you can intercept a package, compromise something critical, like the server BMC or firmware, reseal everything, and be on your way.
And given the relatively recent scare with loads of servers, including Dell and others, being shipped with "AMERICAN MEGATRANDS" labels on their BMC boards, with no one noticing until a YouTube commenter pointed it out during a teardown by ServeTheHome, I think it's totally feasible for an enemy to just compromise the entire physical supply-chain of a company, datacenter, or whatever else [8].
You can try to see if your provider supports "opaque" types in which you can submit the binary encoding of the record without them knowing what it is. Barring that you'll need to request support for it. It's an increasingly popular record type so not supporting it isn't terribly great service nowadays.
I'm not familiar with the discussion that went into the design of CAA (it was probably discussed at some point on the relevant IETF mailing list, if you want to go digging).
I have found that some providers that say they don't support it just mean in their web interface. It may be worth testing if you can set up a hidden primary server and have your provider just be a secondary to it. That is how I managed to get around that restriction with Linode.
Yes, but if you can serve multiple certificates on one endpoint (think SNI) then you can add your own self-signed or private PKI certificate to be able to check if all your requests are being intercepted by a lazy adversary.
The Hetzner one is a physical server. You would need to stage a "power outage" and backdoor it, which is probably not that easy - e.g. planting a kernel module which survives kernel upgrades and is pretty advanced at hiding itself (the article talks about analyzing raw memory dump).
Secure boot on a cloud machine is pretty useless, there's nothing stopping the hypervisor from injecting code into the running machine. Theoretically virtual machine memory is encrypted, but you'll just have to trust the hypervisor's word for it. You can try to verify the boot chain all the way to the hardware keys, but if the hypervisor just replaces your `JNE` with a `NOP` you'll have a hard time automating your protections.
I suppose you can transfer the keys out of the machine over the network (and hope the hypervisor doesn't replace the socket buffers just before transmission) and verify them off site, but guest machines will always be just that: guests on a host that has all the power.
I'm not sure truly verifiable "Secure" Boot is actually realistic in most scenarios, though, right?
I'm not super up-to-date on what's being offered right now, but I'm not sure if there is a way to have a proper trusted execution environment on most Intel or AMD offerings; I thought Secure Boot on AMD64 platforms generally rely on TPM or something like SGX for validation, with the former having seemingly a dozen different ways to be tampered with, and the latter being discontinued and being vulnerable to several different attacks, including DOWNFALL.
I think EPYC and Sapphire Rapids have some sort of Trusted Execution Environment stuff with SEV-SNP and TDX, maybe? But I don't think either option is really feasible for people paying Hetzner-like prices for hosting; Hetzner's newest Xeon offering is seemingly Cascade Lake, and the only EPYC offered is a single-socket Rome 7502P with 128GB DDR4 for 142 euros, which seems very hard to justify, given they also offer a 7950X3D with 128GB DDR5 for ~25 euros less.
Even then, I don't think I could put my confidence in a machine I don't own, didn't setup, can't physically inspect, don't know where it came from, whether the firmware has been tampered with, etc -- especially if it is something as complex as x86, where there is seemingly at least one new horrific hardware-level vulnerability that crops up every generation or two.
EDIT: I forgot Hetzner also started offering Ampere Altra servers for 200 euros. I think those have TEE of some sort with the TrustZone stuff?
Not sure how secure that really is, though; I haven't really looked into the ARM offerings as much as I should have, mostly since, if you don't want Apple, I'm not aware of a good middle-ground between a cheap SBC and a $3,000+ Ampere server, outside of jerry-rigging some second-hand Gigabyte Cavium ThunderX2 nodes off eBay.
Only if secure boot was enabled by a trusted party on trusted hardware.
If you enable secure boot remotely without physical access to the machine you can't be sure it was actually setup in a non-compromised way. For example the machine could be running a custom backdoor-ed TPM, BIOS settings, ...
What is the fundamental technical solution for these kinds of attacks from nation-states and other powerful actors? Is there anything which can satisfy the nerdy dream of software which is freely distributable, yet completely safe from censorship, intervention or mutation by anyone other than its author?
Are properly built P2P systems over the current internet infrastructure a good enough answer? Or should we rolling out a second low-bandwidth global mesh internet working over radio?
I just hope Freenet 2023 evolves to have a zero-friction DX for P2P applications.
A quick warning on hetzner. I needed a personal bare metal machine so signed up.
I was travelling and on an IP in a distant land so their sign up asked for secondary verification via PayPal. All passed and now it’s should get a server?
Nope - next day their support emailed telling me they would not approve my account without… no word of a lie here… either 1: a fax of my passport info page or 2: a scan and email containing the same.
I refused reminding them of GDPR and that email is at best opportunistically encrypted and at worst open to interception.
They replied stating they believed they were GDPR compliant because all they do is use the passport to verify the account and delete the document. They also said I could hide anything sensitive other than my name and date of birth!!
I suggested the process is not GDPR compliant as anyone could intercept unencrypted emails and that they should talk to a lawyer if they did not believe my assertion.
Within a short time the server was approved and online. I queried if they would revise their process in light of our interaction. They did not address the question.
I tried to sign up from The Netherlands for a server hosted in Germany.
They asked me to email them a copy of my ID card for verification. They refused to have me as a customer even after I provided it. I guess they didn't like the look of my face? They refused to tell me how I could still proceed, and I would've happily paid a year in advance or something. Heck, I could've probably visited their office in person.
I did try to register from a Protonmail account because I self-host my email and don't want to run into a chicken-and-egg problem (need to mail them because my server is down, can't mail them because my server is down...), so perhaps that was the issue.
Because Hetzner refused my business I was forced to look for another provider, and I've been using OVH without any issue for a few years now. Quite a shame though, because Hetzner definitely seems to provide a superior service - provided you can get them to take your business!
I absolutely hate any process that requires uploading my passport or other identity documents. I always redact as much as possible and then cover the photo with red text saying "FOR $BUSINESS IDENTITY VERIFICATION ONLY." Sometimes they push back on it, but usually it's acceptable. The worst is when their automated system rejects it.
On email: "While encryption is not required, it is up to every organization to develop a rationale for developing the most appropriate data security practices."
Fax is an accepted GDPR-compliant form of "secure" communication. Yes, many service providers need to ascertain your identity. In my experience, passport photo verification is normal at Hetzner, Hetzner is very aware that not everyone wants to meet the requirements for their service, and they will happily refund you if you decide not to proceed.
This passport verification is required in Germany for any Internet connection. You need to do the same if you sign up for a cellphone plan in Germany. It's a surveillance state.
They had the option to send it encrypted with PGP. But yes, this reminds me of communist countries where you had to leave your ID at the hotel upon check in. The Stasi mentality lingers on and accomplishes nothing.
I think it is less Stasi and more so 30 euro dedicated servers with unmetered gigabit lines are ripe for bad clients.
You've got the general issue of abuse and fraud that all providers face. But I think there are two issues that make it worse for companies like Hetzner, OVH, and other low-cost providers:
1. Chargebacks are a big deal, both in terms of being cut off from payment networks but also the fees imposed, which are especially harsh if your margins are likely razor thin sometimes; looking at the server auctions right now, it's kind of wild that Hetzner manages to give you a place in a datacenter, 3700X, 64GB RAM, 2x1TB enterprise SSDs, and unmetered gigabit on a decent network for 33 euros while still making a profit.
2. I would imagine that attempting the proper credit-card theft kind of fraud is also more of an issue for low-cost providers, not only because of #1, but because I think you'd manage to keep and abuse servers bought with stolen money for a lot longer; I think legitimate owners of said cards are less likely to notice 30 euro charges every month compared to being robbed blind by unexpected AWS fees.
I've had to deal with anti-fraud paranoia from OVH, BuyVM, Hetzner, and many others, likely all for the same reasons as Hetzner.
Both Hetzner and OVH refused to provide me service without photo ID or a passport. BuyVM refused one of my Jordanian friends entirely unless he paid in crypto. And while minor in comparison, I've had to change my PayPal email to match my account email on BuyVM despite it literally previously being paypal@myfirstandlastname.tld.
Not meant to be a dig at BuyVM, btw, even though the crypto bit may seem harsh. I really like them; freedom to host pretty much anything that isn't straight-up illegal, even Tor exit nodes, the support is good, they're often around and transparent in the community chat, and it's hard to beat free BGP announces, up to 10Gbps speeds, anycasted VMs across Europe and the US for <$10/month, and optional $3/month DDoS mitigation -- especially since it's the kind of small enough, tight-ship type of thing to where you can moan about poor routing or custom mitigation filters and potentially have someone actually try to take care of it (and it's also hard to beat for abusive or awful clients too, hence the trouble).
They provide great service, even if only to use as a DDoS-mitigated tunnel for more powerful servers elsewhere, or as a CDN, etc.
Plenty of modern hotels in Western countries require you to submit your passport to reception, who then scans it and keeps a copy of it. In fact Marriot recently suffered a data breach where the attacker obtained the photos of these passports.
Of course, that's not mutually exclusive with Western nations having "The Stasi Mentality..."
> Don't use Cloudflare or similar services. See my article here for an explanation on why. If you use a service like this, you're basically already MitMing yourself.
I wish more people would realize that when arguing on the internet about CAA, DNSSEC, NSA, etc. that none of it really matters. We willingly allow a government aligned entity to unwrap 20% of all TLS connections on the internet and peak inside.
Cloudflare is horrible for privacy. It is also a bit of a sovereignty issue for European countries to have all their citizens web habits to be MITM by a forging power (no matter how friendly they seam).
Edit: not even going in to the sovereignty issue of having an American private company effectively decide your internet regulations.
There are lots of reasons to not use Cloudflare, but many of those given in the article don't hold up. For example, Cloudflare does not set a cookie for all connections, discrimination against Tor users, CAPTCHAs and WAFs are all configurable.
The summary of the attack from https://notes.valdikss.org.ru/jabber.ru-mitm/ is very interesting:
* The attacker managed to issue multiple SSL/TLS certificates via Let’s Encrypt for jabber.ru and xmpp.ru domains since 18 Apr 2023
* The Man-in-the-Middle attack for jabber.ru/xmpp.ru client XMPP traffic decryption confirmed to be in place since at least 21 July 2023 for up to 19 Oct 2023, possibly (not confirmed) since 18 Apr 2023, affected 100% of the connections to XMPP STARTTLS port 5222 (not 5223)
* The attacker failed to reissue TLS certificate and MiTM proxy started to serve expired certificate on port 5222 for jabber.ru domain (Hetzner)
* The MiTM attack stopped shortly after we begun our investigation and network tests on 18 Oct 2023, along with tickets to Hetzner and Linode support team, however passive wiretapping (additional routing hop) is still in place at least on a single Linode server
* Neither servers appear to be hacked
* Both Hetzner and Linode network appear to be reconfigured specifically for this kind of attack for the XMPP service IP addresses
---
Neither that page, nor the page linked from here, mention certificate pinning, maybe because XMPP doesn't support it (I don't know), but if it did, wouldn't that have prevented this kind of attack?
XMPP supports channel binding, which is not mentioned in this post but would have prevented this attack. Unfortunately jabber.ru is running server software from 2016, and that old version doesn't support it.
Pinning is problematic these days, because certificates are short-lived and renewed frequently. Users would be constantly asked to accept new certificates on a monthly basis, and they wouldn't think twice about clicking 'Accept' on an attacker's certificate then.
Channel binding works regardless of the certificate, and ensures the TLS stream is terminated by the entity you exepect.
The focus on (lack of) CT/SCT support in XMPP clients puzzles me, because it would not have detected this attack at all, which used valid CT-logged certs from Let's Encrypt. SCT verification would help detect theoretical issuance from another CA if they had a strict CAA record in place (they did not). But even then, channel binding is more privacy-friendly and does not depend on a third party.
Pinnig is based on the keypair, not the cert. You can renew and not break pinning, right?
Also you can phase in a new cert with pinning.
3 replies →
If you care enough to pin, purchasing actual certificates isn't that hard is it?
> * The attacker failed to reissue TLS certificate and MiTM proxy started to serve expired certificate on port 5222 for jabber.ru domain (Hetzner)
This is gold.
The absolute lack of giving a shit is one of your major clues this was a lawful intercept scenario.
Someone was forced to do it, but they didn’t personally agree with it so they eventually made a “mistake” to tip off the target?
There is the plain incompetence explanation: the hosting provider gave control of the operation to the government entity. The underpaid and indifferent government employee did the best they could with their level motivation and skill level.
I mean, I’ve seen the auto renew fail a lot with the certbot. They definitely should have checked it in the renew period to make sure it was working, but I feel for them
>affected 100% of the connections to XMPP STARTTLS port 5222 (not 5223)
Why did they only target the STARTTLS port? On a related note, I would never use the STARTTLS port (opportunistic encryption) if I knew that the server had a regular TLS port...
>I would never use the STARTTLS port (opportunistic encryption) if I knew that the server had a regular TLS port...
That is what XMPP clients tend to do...
These days XMPP servers tend to default to requiring TLS on both 5222 and 5223 (Let's Encrypt has changed everything). Prosody does this for example. It doesn't even support port 5223 by default anymore. Port 5223 was never an official port assignment.
So it is very possible that the MiTM was only done on port 5222 because that was the only port that clients were using.
Easier to conceal the attack.
The MiTM attacker can pass through a command stream without STARTTLS. If they intercepted 5223 they would have to do their own client-side TLS handshake with the attacked server, which would look really obvious to anybody doing TLS fingerprinting on the server: all of a sudden, 100% of their clients have the exact same TLS fingerprint.
Stop outsourcing your PKI to ICANN, folks. Domains are not public keys.
4 replies →
It is pretty simple. 5223 port is called "legacy SSL". So, because it is legacy, clients would, by default, use 5222 + starttls. I.e. majority of clients connect with 5222.
Also, I've never understood why they've moved 5223 (regular TLS) into deprecated. It was pretty useful to enable SSL on AWS ELB on this port. Which is not possible with 5222, because it does XML stuff before switching to TLS.
I would speculate it is to not keep 2 ports open or something, was a reason to move it to deprecated. + you can do some cleartext communication before switching to TLS (not like it is that useful).
>The attacker managed to issue multiple SSL/TLS certificates via Let’s Encrypt
This implies that the attacker was able to validate domain ownership of jabber.ru and xmpp.ru by either a) being able to respond to the ACME protocol on domain(s) hosted http OR b) being able to write to a DNS TXT file for the domain(s). This implies that the victim already lost control of their process server and/or their nameserver.
No. Most probably it merely implies someone upstream of them (presumably their hosting provider under compulsion from German law enforcement) intercepted and spoofed their unencrypted, unauthenticated ACME HTTP traffic.
Same can happen to you.
7 replies →
On April 3rd the IP address for ns1.jabber.ru was changed [1]. Two weeks later the first LetsEncrypt certificate was issued. Could be related?
1. https://dns.coffee/nameservers/ns1.jabber.ru
How would you do certificate pinning if you don't control the clients?
My understanding is that certificate pinning is only possible if you control the clients, in which case you can embed which certificates are allowed directly in the client and bypass the whole web PKI.
In a situation with general-purpose clients connecting, how would they know which certificates are meant to be allowed? That's what the web PKI is used for.
Of course, if you do provide your own clients, this just moves the problem further up the chain - in this case the place where customers would download the custom client software would be compromised and a malicious client served instead.
> How would you do certificate pinning if you don't control the clients?
Well you cannot. If you were paranoid, you would perhaps supply a hash through some out-of-band mechanism, which would require manually updating for each new cert.
Obviously most people wouldn't ever want to do that.
Isn't this what those "key hash pictures" in WhatsApp/Signal are solving?
XMPP clients could implement such a mechanism, and if any certificate/domain along the path changes, the users in a conversation would be notified.
1 reply →
TLS client certificates.
Use them.
Stop using domains. Stop.
1 reply →
> Both Hetzner and Linode network appear to be reconfigured specifically for this kind of attack for the XMPP service IP addresses
This suggests a compromise of Hetzner and Linode network management.
> This suggests a compromise of Hetzner and Linode network management.
No it doesn't. It suggests that they both complied with a request from law enforcement.
3 replies →
More likely the carrier upstream of them.
1 reply →
Is it given that this attack was done from within Hetzner?
As I understand the techniques applied; this could have also been done at another place on the network route to the targeted server.
Ie. by the telecommunications company delivering traffic into Hetzner.
Tele communication companies have internal “police groups” (where I am from - I expect it to be the same in Germany) that does nothing but service wiretapping requests from the police. Telcos are required by law to do this.
Them expanding into mtm https wiretapping is a new for me but maybe to be expected …
This list lacks the most obvious one: enable (and ideally enforce) SCRAM-xxxxx-PLUS as the authentication method of choice.
The idea of the PLUS variant is both simple and effective: instead of verifying <user,password> with the help of a salt you are verify <user,password,tls session key>.
That way the authenticating is only valid on a single TLS connection.
This is also called channel binding.
Who are the end users of xmpp.ru and jabber.ru? Are they hoping to pick up traffic between Russian soldiers? Spies? I hate mass surveillance as much as the next guy but why target Russian domains specifically?
I can't imagine it is war-related, or at least not in any direct sense, like literally trying to intercept soldiers or spies.
I think the more likely scenario is that someone was to catch carders/botnet operators, since Jabber/XMPP is still very popular amongst people in that scene in Russia; you'll see often see screenshots or logs containing @exploit.in, @jabber.ru, and various other servers pretty much in any Krebs on Security article, for example.
That said, I think mass-surveillance is usually pretty gross regardless of intent.
I don't know what the exact ratio of criminal to non-criminal usage of either server is, but just like how Tor simultaneously has a ton of obviously illegal content mixed with whatever percentage of legitimate use [1], they presumably still do have a fair amount of totally normal conversations going on. And so I'm not an exactly a huge fan of invading privacy in order to spy on random cybercriminals likely far out of your jurisdiction in countries unwilling to extradite in the first place.
And while I understand if Hetzner was forced to comply, unless they wanted to become another Lavabit, as someone who recommends them often, it'll still be a little disappointing, IMO, if it turns out they were aware and allowed or assisted in the MitM attack, because otherwise, I think they're one of the best hosting companies.
Their transparency is great. And I get better uptime, reliability, and support than the overwhelming majority of cloud providers without selling my organs to afford it. And their effort put into turning environmentally-friendly design choices into economically smart choices is commendable.
The "reduce" in reduce > reuse > recycle can be seen in their KISS designs—like the raised, angled roof, allowing natural heat escape rather than loads of HVAC [2]; server chassises that are more bare-minimum structural support and air-shrouds than actual chassises; and stripped-down standard motherboard designs with only the most minimal changes, like 90-degree rotated sockets to allow a single fan to cool the VRM, CPU, and memory [3], rather than a dozen screaming, power-slurping Delta fans for every server.
And their knowledge of "reuse" is evident by their server auctions, where they do Dutch-auction-style rentals of legacy hardware rather than scrapping everything, avoiding spending a load on new hardware while also avoiding the environmental cost associated with manufacturing new everything each generation.
I'd love to be able use them more if only they had dedicated servers outside of Europe.
[1]: "legitimate" is hard to define anyway; one country's journalist is another's "foreign agent", and one country's "freedom fighter" is another's "terrorist".
[2]: Der8auer: Over 200,000 Servers in One Place! Visiting Hetzner in Falkenstein - https://youtu.be/5eo8nz_niiM?t=259
[3]: Der8auer: Hetzner shows Special AM5 Board with 90° Rotated Socket - https://youtu.be/V2P8mjWRqpk
> I can't imagine it is war-related, or at least not in any direct sense, like literally trying to intercept soldiers or spies.
The Ukrainian military has been using Discord, so it's not totally unimaginable. Are these domains administered by Russians? IMO it would be pretty naive for Russians to be hosting comm servers in NATO datacenters right now. Perhaps related: I interviewed for a job recently where the hiring manager was a Russian immigrant. He was telling me I should go visit St. Petersburg and didn't seem to understand that is not an option at the moment. I was flattered by the suggestion of course and it is a nice reminder that regular people are typically tolerant, but also confused. Do people not understand the severity of the situation or is this behavior of acting like it is business as usual a coping mechanism?
1 reply →
> I can't imagine it is war-related, or at least not in any direct sense, like literally trying to intercept soldiers or spies.
Perhaps a majority of war between technologically developed countries these days occurs on the internet - just because no soldiers or spies are involved in something, that doesn't mean it isn't direct war. Example: propaganda around Russia/Ukraine last year and Israel/Palestine this year
[dead]
They point out that "CT is optional", but isn't that ultimately a decision by the XMPP clients? What stops them from requiring CT now that browsers effectively do? What trust store would they be relying on that issues certificates that don't work in the browser?
Right, they could do this and this seems like a good idea to me. The problem this require-CT behaviour isn't switched on by default for basically any TLS library, so an XMPP client developer would have to go out of their way to switch this on, and I assume most or all (currently) don't. That can change of course.
How problematic is that in real life? All CAs worth their salt are already publishing all certificates to CT logs because most TLS servers are browsers and most clients are browsers.
Maybe there's a CA somewhere that has opt-in CT logging enabled, but I don't think they're very popular. For example, even the rogue CA certificates were published onto the CT log (because Let's Encrypt does so by default).
I think a CT check shouldn't be a very problematic change in practice, as long as there are reasonable exemptions (i.e. don't require CT for certificates imported into the CA store, allow the user to disable the check, etc.). For server<->server communication things become more difficult, but the entire network would be better off if a major server like ejabberd were to require CT.
This article suggests using OTR with XMPP, unfortunately OTRv3 is using obsolete crypto and OTRv4 hasn't been finalised.
https://dustri.org/b/time-to-sunset-otr.html
> What would a perfect attacker do?
If you had physical access to the computer, some sort of bus interception to exfiltrate data from the machine.
Thinking laterally for a moment regarding the big picture here, why do we still rely on data centres.
They made sense in a world of dialup and low speed / high latency broadband. But there are lots of places with high speed fibre and not much latency to the peering points.
And the more we break away from data centres and clouds, the more the internet infrastructure will have to work the way it was designed instead of having to flow through these crazy aggregation points that are both serious points of failure and major security risks.
> They made sense in a world of dialup and low speed / high latency broadband. But there are lots of places with high speed fibre and not much latency to the peering points.
Yes, but then you need backup power, someone to replace disks / hardware if things break, proper security for compliance reasons, cooling, noise. Once you set up all these things you just invented a data center again.
I don't see how getting rid of data centers makes any sense.
1 reply →
Regular domestic connections often block ports (especially email). In many countries, ISPs won't sell you a static IP (your dynamic address might not change ever, but you don't control rDNS records).
These kind of measures force people to move onto a rented server instead. Often ISPs rent servers themselves. The conflict of interest here is hard to ignore: if ISPs make it easy and convenient to host from home, their business of renting servers suffers.
IP addresses, IP addresses, IP addresses, IP addresses.
extremely difficult to get physical access in a datacenter
All the people working in the datacenter have that level of physical access.
Unless they are very closely supervised they can do a lot of damage without anybody being the wiser until they get caught. I've been in (nominally very secure) DCs on behalf of customers and I've seen:
- unlocked racks
- doors open
- temporary network cables and keyboards, monitors and mice attached to running systems
- systems logged in left unattended
- floor panels raised up and left open unattended exposing cabling
- meet-me rooms with interfaces exposed (gear in racks without doors)
DC personnel tends to trust each other, and they probably shouldn't. But it's hard to be part of a closely knit crew for a long time without getting into a 'get stuff done' mode where protocol and rules are there in principle but less so in practice because it is seen as an efficiency penalty. It's another instance of the 'normalization of deviation' phenomenon.
3 replies →
The organization conducting the MitM likely has physical access to the machine already. The original post indicates the link on the network interface went down for 19 seconds, indicating a device was placed in front of the server.
Sure but this is the German police and more generally nation states, not only they can, they don't even need to they just ask
1 reply →
I would suggest that if you are the police, you can break into a datacenter with a flash of a badge. I can't imagine many would attempt to stop you.
14 replies →
Assuming this was done at the government's request, I assume Hetzner is more than willing to comply with a court order mandating they allow them to monitor and physically size a machine.
And outside of nation-state requests, even ignoring the fact that someone could probably pay-off an employee, I think ease would depend a lot on the datacenter and target; judging by the awesome and hilarious story behind the Fremont Cabal accidentally becoming an internet exchange by essentially having some dude barely secretly slipping unauthorized cables into the raceways [1], I figure there are a lot of places where if your target is simply renting a couple rack units or single rack rather than an entire locked cage, you can probably get physical access by doing the same.
Also, a lot of Deviant Ollam's stories about industrial security and the dozens of ways he's broken into utility companies, server rooms, etc — mostly just by being confident, looking the part, bad doors [2], and badge cloning [3] — don't give me a ton of confidence that someone with skill couldn't feasibly either get direct access to servers they shouldn't, or at the very least, access to an important part of the supply chain for their target.
And speaking of supply chain, my processor died recently, so I ordered a brand-new in box replacement Ryzen, and when it arrived last night, out of curiosity, I wanted to see if I could get the CPU out of the box without breaking the tamper-evident authenticity seal...
... and about fifteen minutes later, after borrowing a syringe and hypodermic needle from my mom, a little bit of isopropyl alcohol, a blade from my safety razor, and a quick look at a video from LockPickingLawyer [4] and a couple from datagram at DEFCON's Tamper-Evident Village [5][6], I had the CPU out, put my old one for now, and re-applied the sticker with no visible damage to the box or seal.
All I had to do was tip it upside down at about 90-degrees, douse a little bit of the alcohol under the top of the seal, let gravity do most of the work, and then carefully lift the seal with the razor. After that, I just lightly squeezed the box to make the front tab come as forward as possible, and then carefully pushed the ear flaps down to prevent tearing, and then I was in.
I've seen others demonstrate it on older AMD boxes that had flexible cardboard in-place of the cooler, allowing them to pull the cardboard to make enough room for tools to get out the CPU without even touching the seal [7]. But in my case, it was a newer box with hard plastic inside where the cooler would've been, so that's why I went for the seal instead.
No surprise to me now that counterfeiting is rampant on Amazon, with people returning the box after putting in either random junk, dead Athlons covered by a counterfeit serial-matching IHS, or the cheapest socket-compatible CPU after deluding both and swapping the IHS.
I figure with a bit of practice and better tools, like Teflon spudgers and syringes, it'd be significantly easier to get past 99% of tamper-resistant/tamper-evident seals and into boxes you're not supposed to be without risking damage, and then you can intercept a package, compromise something critical, like the server BMC or firmware, reseal everything, and be on your way.
And given the relatively recent scare with loads of servers, including Dell and others, being shipped with "AMERICAN MEGATRANDS" labels on their BMC boards, with no one noticing until a YouTube commenter pointed it out during a teardown by ServeTheHome, I think it's totally feasible for an enemy to just compromise the entire physical supply-chain of a company, datacenter, or whatever else [8].
[1]: Oxide's On the Metal: Kenneth Finnegan - https://oxide.computer/podcasts/on-the-metal/kenneth-finnega...
[2]: Deviant Ollam @ Shakacon: The Search for the Perfect Door - https://www.youtube.com/watch?v=4YYvBLAF4T8
[3]: Deviant Ollam / Modern Rogue: Getting an RFID Implant - https://youtu.be/SZiRISGdQ4g?t=277
[4]: LockPickingLawyer: Did I Cheat On This Challenge? (Tamper-Sealed Abus) - https://www.youtube.com/watch?v=xUJtqvYDnkg
[5]: DEFCON 19: Introduction to Tamper Evident Devices - https://www.youtube.com/watch?v=W07ZpEv9Sog
[6]: DEFCON 30: Tamper Evident Village - https://www.youtube.com/watch?v=slhdowWjSuU
[7]: cycurious: How Counterfeiters replace CPU in Sealed Retail Box - https://www.youtube.com/watch?v=Bni8bgGlXDE
[8]: ServeTheHome: Dude this should NOT be in a Dell Switch… or HPE Supercomputer - https://www.servethehome.com/dude-dell-hpe-ami-american-mega...
2 replies →
I looked into CAA but the current dns provider doesn't support those records. Is there a reason it had to be a new type not a more common TXT record?
You can try to see if your provider supports "opaque" types in which you can submit the binary encoding of the record without them knowing what it is. Barring that you'll need to request support for it. It's an increasingly popular record type so not supporting it isn't terribly great service nowadays.
I'm not familiar with the discussion that went into the design of CAA (it was probably discussed at some point on the relevant IETF mailing list, if you want to go digging).
See RFC5507: "Why Adding a New Resource Record Type Is the Preferred Solution"
DNS providers should support a wide range of RR types, and domain owners should vote with their NS records.
See https://github.com/StackExchange/dnscontrol/blob/master/docu... for a list of DNS providers that support CAA.
I have found that some providers that say they don't support it just mean in their web interface. It may be worth testing if you can set up a hidden primary server and have your provider just be a secondary to it. That is how I managed to get around that restriction with Linode.
Run your own CA and choose your roots carefully didn't make the cut.
A bit difficult when providing services to third parties who can use any client software :-/
That's actually probably easier than getting a browser to work with a forbidden cert, how dare you.
Yes, but if you can serve multiple certificates on one endpoint (think SNI) then you can add your own self-signed or private PKI certificate to be able to check if all your requests are being intercepted by a lazy adversary.
The provider has access to the host, they can just inspect the job from the outside and you won’t be able to tell
The Hetzner one is a physical server. You would need to stage a "power outage" and backdoor it, which is probably not that easy - e.g. planting a kernel module which survives kernel upgrades and is pretty advanced at hiding itself (the article talks about analyzing raw memory dump).
If it was big brother, obtaining a customised EUFI or ilo/drac/ipmi firmware for the hardware doesn't seem like a stretch.
It only takes access to a DMA-enabled bus (e.g. PCIe) though, to siphon memory contents.
1 reply →
secure boot + virtualized memory encryption is supposed to prevent that, you'll have to trust intel/amd though.
Secure boot on a cloud machine is pretty useless, there's nothing stopping the hypervisor from injecting code into the running machine. Theoretically virtual machine memory is encrypted, but you'll just have to trust the hypervisor's word for it. You can try to verify the boot chain all the way to the hardware keys, but if the hypervisor just replaces your `JNE` with a `NOP` you'll have a hard time automating your protections.
I suppose you can transfer the keys out of the machine over the network (and hope the hypervisor doesn't replace the socket buffers just before transmission) and verify them off site, but guest machines will always be just that: guests on a host that has all the power.
3 replies →
I'm not sure truly verifiable "Secure" Boot is actually realistic in most scenarios, though, right?
I'm not super up-to-date on what's being offered right now, but I'm not sure if there is a way to have a proper trusted execution environment on most Intel or AMD offerings; I thought Secure Boot on AMD64 platforms generally rely on TPM or something like SGX for validation, with the former having seemingly a dozen different ways to be tampered with, and the latter being discontinued and being vulnerable to several different attacks, including DOWNFALL.
I think EPYC and Sapphire Rapids have some sort of Trusted Execution Environment stuff with SEV-SNP and TDX, maybe? But I don't think either option is really feasible for people paying Hetzner-like prices for hosting; Hetzner's newest Xeon offering is seemingly Cascade Lake, and the only EPYC offered is a single-socket Rome 7502P with 128GB DDR4 for 142 euros, which seems very hard to justify, given they also offer a 7950X3D with 128GB DDR5 for ~25 euros less.
Even then, I don't think I could put my confidence in a machine I don't own, didn't setup, can't physically inspect, don't know where it came from, whether the firmware has been tampered with, etc -- especially if it is something as complex as x86, where there is seemingly at least one new horrific hardware-level vulnerability that crops up every generation or two.
EDIT: I forgot Hetzner also started offering Ampere Altra servers for 200 euros. I think those have TEE of some sort with the TrustZone stuff?
Not sure how secure that really is, though; I haven't really looked into the ARM offerings as much as I should have, mostly since, if you don't want Apple, I'm not aware of a good middle-ground between a cheap SBC and a $3,000+ Ampere server, outside of jerry-rigging some second-hand Gigabyte Cavium ThunderX2 nodes off eBay.
Only if secure boot was enabled by a trusted party on trusted hardware.
If you enable secure boot remotely without physical access to the machine you can't be sure it was actually setup in a non-compromised way. For example the machine could be running a custom backdoor-ed TPM, BIOS settings, ...
Those are best for compliance to security requirements/ standards. They're not for security against state level actors.
But for some reason the attackers did not use backdoor access to the servers in this case.
What is the fundamental technical solution for these kinds of attacks from nation-states and other powerful actors? Is there anything which can satisfy the nerdy dream of software which is freely distributable, yet completely safe from censorship, intervention or mutation by anyone other than its author?
Are properly built P2P systems over the current internet infrastructure a good enough answer? Or should we rolling out a second low-bandwidth global mesh internet working over radio?
I just hope Freenet 2023 evolves to have a zero-friction DX for P2P applications.
A quick warning on hetzner. I needed a personal bare metal machine so signed up.
I was travelling and on an IP in a distant land so their sign up asked for secondary verification via PayPal. All passed and now it’s should get a server?
Nope - next day their support emailed telling me they would not approve my account without… no word of a lie here… either 1: a fax of my passport info page or 2: a scan and email containing the same.
I refused reminding them of GDPR and that email is at best opportunistically encrypted and at worst open to interception.
They replied stating they believed they were GDPR compliant because all they do is use the passport to verify the account and delete the document. They also said I could hide anything sensitive other than my name and date of birth!!
I suggested the process is not GDPR compliant as anyone could intercept unencrypted emails and that they should talk to a lawyer if they did not believe my assertion.
Within a short time the server was approved and online. I queried if they would revise their process in light of our interaction. They did not address the question.
I tried to sign up from The Netherlands for a server hosted in Germany.
They asked me to email them a copy of my ID card for verification. They refused to have me as a customer even after I provided it. I guess they didn't like the look of my face? They refused to tell me how I could still proceed, and I would've happily paid a year in advance or something. Heck, I could've probably visited their office in person.
I did try to register from a Protonmail account because I self-host my email and don't want to run into a chicken-and-egg problem (need to mail them because my server is down, can't mail them because my server is down...), so perhaps that was the issue.
Because Hetzner refused my business I was forced to look for another provider, and I've been using OVH without any issue for a few years now. Quite a shame though, because Hetzner definitely seems to provide a superior service - provided you can get them to take your business!
When was this? Few years ago, something similar happend to me but they provided pub gpg key that i could use..
The same thing happened to me with OVH. They asked for a photo of myself holding government issued ID for verification.
I simply sent a short email reply saying that seemed excessive for just renting a VPS and their support allowed me to continue.
Since then, I've switched to Contabo hosting which seems to offer cheaper pricing. Would recommend to a friend .
I absolutely hate any process that requires uploading my passport or other identity documents. I always redact as much as possible and then cover the photo with red text saying "FOR $BUSINESS IDENTITY VERIFICATION ONLY." Sometimes they push back on it, but usually it's acceptable. The worst is when their automated system rejects it.
https://gdpr.eu/email-encryption/
On email: "While encryption is not required, it is up to every organization to develop a rationale for developing the most appropriate data security practices."
You should probably apologise for being wrong.
Fax is an accepted GDPR-compliant form of "secure" communication. Yes, many service providers need to ascertain your identity. In my experience, passport photo verification is normal at Hetzner, Hetzner is very aware that not everyone wants to meet the requirements for their service, and they will happily refund you if you decide not to proceed.
This passport verification is required in Germany for any Internet connection. You need to do the same if you sign up for a cellphone plan in Germany. It's a surveillance state.
They had the option to send it encrypted with PGP. But yes, this reminds me of communist countries where you had to leave your ID at the hotel upon check in. The Stasi mentality lingers on and accomplishes nothing.
I think it is less Stasi and more so 30 euro dedicated servers with unmetered gigabit lines are ripe for bad clients.
You've got the general issue of abuse and fraud that all providers face. But I think there are two issues that make it worse for companies like Hetzner, OVH, and other low-cost providers:
1. Chargebacks are a big deal, both in terms of being cut off from payment networks but also the fees imposed, which are especially harsh if your margins are likely razor thin sometimes; looking at the server auctions right now, it's kind of wild that Hetzner manages to give you a place in a datacenter, 3700X, 64GB RAM, 2x1TB enterprise SSDs, and unmetered gigabit on a decent network for 33 euros while still making a profit.
2. I would imagine that attempting the proper credit-card theft kind of fraud is also more of an issue for low-cost providers, not only because of #1, but because I think you'd manage to keep and abuse servers bought with stolen money for a lot longer; I think legitimate owners of said cards are less likely to notice 30 euro charges every month compared to being robbed blind by unexpected AWS fees.
I've had to deal with anti-fraud paranoia from OVH, BuyVM, Hetzner, and many others, likely all for the same reasons as Hetzner.
Both Hetzner and OVH refused to provide me service without photo ID or a passport. BuyVM refused one of my Jordanian friends entirely unless he paid in crypto. And while minor in comparison, I've had to change my PayPal email to match my account email on BuyVM despite it literally previously being paypal@myfirstandlastname.tld.
Not meant to be a dig at BuyVM, btw, even though the crypto bit may seem harsh. I really like them; freedom to host pretty much anything that isn't straight-up illegal, even Tor exit nodes, the support is good, they're often around and transparent in the community chat, and it's hard to beat free BGP announces, up to 10Gbps speeds, anycasted VMs across Europe and the US for <$10/month, and optional $3/month DDoS mitigation -- especially since it's the kind of small enough, tight-ship type of thing to where you can moan about poor routing or custom mitigation filters and potentially have someone actually try to take care of it (and it's also hard to beat for abusive or awful clients too, hence the trouble).
They provide great service, even if only to use as a DDoS-mitigated tunnel for more powerful servers elsewhere, or as a CDN, etc.
1 reply →
Plenty of modern hotels in Western countries require you to submit your passport to reception, who then scans it and keeps a copy of it. In fact Marriot recently suffered a data breach where the attacker obtained the photos of these passports.
Of course, that's not mutually exclusive with Western nations having "The Stasi Mentality..."
3 replies →
What does this have to do with lingering Stasi mentality? Gunzenhausen was in West Germany.
You don't seem to know anything about VPS administration.
Which GDPR article did you have in mind?
Great callout:
> Don't use Cloudflare or similar services. See my article here for an explanation on why. If you use a service like this, you're basically already MitMing yourself.
I wish more people would realize that when arguing on the internet about CAA, DNSSEC, NSA, etc. that none of it really matters. We willingly allow a government aligned entity to unwrap 20% of all TLS connections on the internet and peak inside.
Cloudflare is horrible for privacy. It is also a bit of a sovereignty issue for European countries to have all their citizens web habits to be MITM by a forging power (no matter how friendly they seam).
Edit: not even going in to the sovereignty issue of having an American private company effectively decide your internet regulations.
Cloudflare exists out of necessity for the most part. The alternatives to shield from large scale DDoS are all US American too.
10 replies →
The EU regularly de-facto tries to decide regulations for other countries. All is fair in a globally connected world.
4 replies →
There are lots of reasons to not use Cloudflare, but many of those given in the article don't hold up. For example, Cloudflare does not set a cookie for all connections, discrimination against Tor users, CAPTCHAs and WAFs are all configurable.
Cloudflare encourages all these bad things by making them simple checkboxes and insinuating that if you care about security you'll check the checkbox.