Chobbes @ Chobbes @lemmy.world

Posts

0

Comments

465

Joined

2 yr. ago

Why do you say a TPM prevents users from running malicious software? As far as I know that’s not really what they’re used for.

I’m pretty sure this is on a public mailing list.

Post quantum cryptography is under development and is slowly being introduced in order to evaluate it / prevent store-and-decrypt-later attacks... But this is generally in more niche applications. SSH recently adopted post-quantum cryptography for key exchange, but it uses a hybrid approach with traditional cryptography in case the post-quantum stuff proves to be not as strong as we think... Signal is experimenting with post-quantum stuff as well. As far as I know, though, post-quantum cryptograhy hasn't seen wide deployment, and I don't think any of it is used with HTTPS yet (certainly not commonly, anyway). Depending on what you care about this could be a problem. If you just care that nobody else can authenticate as you, then yeah, once everything is moved over to post-quantum stuff you can just change all your passwords and hopefully you'll be good... If you care that the data is private then this is a big problem, and in theory somebody could scrape all of the messages you've sent and the contents of everything that you've done on the web (probably government agencies and not normal people, but maybe this information later gets leaked to the public too). This could also be a problem for authentication, for instance if you've ever logged into your bank account you've probably seen your routing numbers which somebody could take and use to transfer money, in theory.

It's also worth noting that, as far as I know, we don't actually know for certain that the post-quantum cryptography we've developed is secure. I think all we know is that it isn't vulnerable to Shor's algorithm, but there could be other exploits we don't know about. This is of course also true for all of the cryptography we use today too. We don't actually know how hard factoring into prime numbers is, for instance, but these algorithms have been in use for a long time and have been under a lot of scrutiny so we have more confidence in them.

How else are you going to browse the web on your fridge?

God this reminds me that it took Firefox forever to support security keys natively. I hope PassKeys are implemented quickly in Firefox if they take off.

Firefox usage has plummeted. To be fair, 2% isn’t a huge slice of the pie, but it’s still a pretty large number of users in absolute terms.

Audio drivers have never really been a problem in my experience, but maybe you’re referring to pulseaudio? In which case, pipewire has been great!

You know, I always used to think praying was incredibly stupid, and I’m sure plenty of people treat it in a way that’s… not really in the right spirit / ineffective? But recently it’s started to make a lot more sense to me. If you’re praying to god in an effort to directly influence the real world I think you’re misguided… If you think of prayer as a time to consider what you’re grateful for and what you want for the future, it actually seems like a really sensible mental health practice. To be clear, I am and always have been an atheist, and I don’t particularly like religions as a whole, but it seems like some of these things I’ve always found odd (like prayer) stem from something that could actually be reasonable and helpful but got corrupted by some game of telephone and people not understanding metaphors lol.

The steam version is actually pretty approachable. You can mostly learn all of the systems on your own time. You don’t have to interact with everything at first.

This is what I thought too, but in my case it turned out my drive was busted and btrfs detected an error and went read only… which was super annoying and my initial reaction was “ugh, piece of shit filesystem!” But ultimately I’m grateful it noticed something was wrong with the drive. If I was just using ext4 I just would have had silent data corruption. In that sense other filesystems do silently do their jobs… but they also potentially fail silently which is a little scary. Checksums are nice.

The creative director for the sequel died unexpectedly this year :(. It feels like a cursed game.

I'm not responding to that comment?

Neither TLS provide in such case. Attacker can request ACME cert.

Depends whose DNS you can mess with, but yes! It may be possible to poison DNS records for one e-mail server, but ACME certificate providers like letsencrypt (supposedly) try to do DNS lookups from multiple locations (so hopefully a simple man-in-the-middle attack will not be sufficient), and they do lookups directly from the authoritative DNS servers. This is, of course, not perfect and theoretically suffers from all of the same mitm problems, but it's more thorough than most mail servers will be and would potentially limit who would be in the position to perform these attacks and get a bogus certificate issued.

With DNSSEC and DANE you are even able to specify which TLS certificate should be used for a service in a TLSA record, and you can protect your A records and your CAA record which should make it much harder to get bogus certificates issued. Of course you need to trust the TLDs in order to trust DNSSEC, but you already do implicitly (as you point out, if you control the TLD you can get whatever certificate you want issued through ACME). The reality right now is that all trust on the web ultimately stems from the TLDs and DNS, but the current situation with CAs introduces several potential attack vectors. The internet is certainly a lot more secure than it used to be even 10 years ago, but I think there's still a lot of work to be done. DNSSEC, or something like it, would go a long way to solving some of the remaining issues.

That depends on the specific TLS setup. Badly configured TLS 1.2 would allow downgrade attacks, TLS 1.3 would not.

Why would TLS 1.3 prevent this kind of downgrade attack? The issue is that TLS has never been a requirement for e-mail servers, so for interoperability they only do TLS opportunistically. Even if you configure your own e-mail server to only talk over TLS, nobody else knows that your server only speaks TLS (or speaks TLS at all), so if somebody is pretending to be your mail server they can just claim to only speak plain text and any sender will be more than happy to default to it. If you support DNSSEC you can use DANE to advertise that your mail server speaks TLS, and even fix the certificates that are allowed, but senders will actually have to check this in order to make sure nobody can intercept your e-mail. Notably both outlook and gmail do not support this (neither for sending nor receiving!), they both instead rely on the weaker MTA-STS standard.

my guess would be that at least the big ones like gmail don’t allow unsecured communication with their servers at all

They absolutely do :).

I highly doubt the “in most circumstances” line

That was maybe too strong of a statement, at least with the recent adoption of MTA-STS this is at least less trivial to do :). The intent of this statement was more "if you are in the position to be a man-in-the-middle between two generic e-mail servers it is trivial to downgrade the connection from TLS to plaintext". I wouldn't be surprised if it was hard-coded that gmail and outlook should only talk to each other over TLS, for instance, which should prevent this for e-mails sent between the two (I also wouldn't be surprised if this wasn't hard-coded either... There's sort of a bad track record with e-mail security, and the lack of DNSSEC from either of these parties is disappointing!). Ignoring special configuration like this, and without MTA-STS or DANE these downgrade attacks are trivial. Now with the advent of MTA-STS you'll probably have a reasonably hard time downgrading the connections between some of the large e-mail providers. Though notably this is not universally supported either, iCloud supports neither MTA-STS nor DANE for instance, and who knows about all of the various providers you never think of. This is a bit of a tangent, but a good talk about how large mail providers might not be as well configured as you'd hope: https://www.youtube.com/watch?v=NwnT15q_PS8

AFAIK DKIM/DMARC now is mandatory on most servers.

DKIM and DMARC don't have anything to do with this. DKIM is a way for e-mail servers to sign e-mails with a key that's placed in DNS in an attempt to prevent e-mail spoofing, but this in no way protects e-mails you send from potentially being read in plain text. DKIM is also not necessarily mandatory, and you can potentially get away with just SPF. Many mail servers also do not have strict sender policies, which could potentially allow for spoofing in certain situations. Also neither DKIM / SPF provide any protections if an attacker is able to poison DNS records.

GPG. Or other E2EE.

I mean, yes, but that's not really the point. PGP has essentially nothing to do with the e-mail protocols aside from the S/MIME extensions. Almost no institution is using PGP to secure e-mails. You could also encrypt something using PGP before you sent it over the fax lines in theory.

In my experience with my Apple Watch you have to activate the wallet functionality in order to pay for something by clicking the side button twice, which should make it harder for somebody to just walk around with a terminal charging random people. Phones usually need to be unlocked to make payments too. In theory NFC credit cards could be scanned like this, and if you're worried about that you can look into NFC blocking wallets... I'm not super worried about it, though, because usually you wouldn't be on the hook for such a fraudulent charge.

Nowdays client-server and server-server communication is ecrypted and signed, so no an issue now.

This is probably true, but in a very unsatisfying way. It's not accurate to say this is not an issue now because mail servers talk to each other with opportunistic encryption --- if both ends say "hey, I support TLS" they'll talk over TLS, but if either end claims to not support TLS they'll default to plain text. This is deeply concerning because it's very possible for somebody to mimic another server and get the connection downgraded to plain text, bypassing TLS altogether. There are standards to deal with this, like DANE, but most large e-mail providers don't support this... The other more recent standard to address this is called MTA-STS, but it's much weaker than DANE and can potentially be exploited (but at least gmail and outlook support it, I guess). E-mail security is in a weird place. It's slightly better than the "completely unencrypted" situation that people seem to think it is... But it's also pretty much impossible to guarantee that your e-mail will not be sent over plain text.

No, they are not. They are not end-to-end encrypted but they are encrypted between your PC and your service provider, between service providers and between service providers and receivers. End-to-end encryption is needed to defend against your service provider or entities that can order your provider around but not against random hackers snooping around in your network.

This is true AND untrue at the same time! It's true that most e-mail providers will talk to other e-mail providers with TLS, but it's trivial to downgrade the connection in most circumstances. If you can man-in-the-middle e-mail servers you can just say "hey, I'm the e-mail provider you're trying to talk to, I don't support TLS, talk to me in plain text!" and the senders will probably oblige. There's a few standards to try to address this problem, like DANE (which actually solves the problem, but is unsupported by all large e-mail providers), and mta-sts which is a much weaker standard (but supported by gmail and outlook). In practice there's a good chance that your e-mail is reasonably well secured, but it's absolutely not a guarantee.

They're just suggesting that you should accept both cash and electronic payments.

It’s also just a way to ping you and see if you’re there and ready to continue a conversation politely / small talk and a way to start talking again.