I'm seeing invalid certificate warnings all across allegro.cc. Anyone else?

Yup, got that as well, added an exception.

But what if the Russians hack A.cc now, we'll never know with a broken cert!

We might have a while to wait if Matthew says he'll check back next year - I think LetsEncrypt certs only last 3 or 4 months

Has anyone managed to get in touch with him?

I've heard he's "away" for the moment so sit tight. It might be a week or two. For all intents and purposes, the only thing we need the encryption for is login and identity.

I recommend against logging in using an A.cc account while the certificate is buggered, but otherwise it doesn't really impact us in a huge way. In theory, a man in the middle could hijack your session and post as you, or steal your A.cc account, but that doesn't accomplish much so I doubt anybody would.

I think that if you login with Google or another provider it won't be sending any passwords in plaintext so at least you won't be exposing any passwords (whereas logging directly into A.cc might). If you're already logged in to A.cc you are probably OK as long as your session doesn't expire. Again, worst case somebody hijacks your account.

Coincidentally, this also applies to my noobish posts here back in the mid-00s. Entirely the fault of the Russians. You have no proof otherwise

I already described the consequences. In theory, the connection is still secure (I hope), but the certificate is no longer valid. This might make it possible for a man in the middle attack, which means your account could be hijacked (session cookies stolen, but if ML is checking IP that might not even be feasible for an existing session). If you login anew then it's possible your password could be revealed in plaintext to a man-in-the-middle. These are both probably unlikely to occur, but should be taken seriously anyway. Consider this practice for when your online bank does this. I'm honestly not too sure the difference between checking the "permanent" exception checkbox and not. In my experience, the connect is typically permitted afterward either way. I'm not sure if the non-permanent one expires after some time, but that would be my hope (I've always assumed it was a broken feature in Firefox).

The concerning thing is that the phrasing of one of the browser's error messages (possibly Firefox, I'm not sure anymore) made it sound like because the certificate was no longer trusted it wasn't even used. I.e., the connection was made without encryption. I'd really like to think that was just a UI bug, and ultimately the connection was secure. Why would it not be? Using compromised encryption is no worse than plaintext. But the point is that the UI didn't explicitly communicate that yes, this connection is still being encrypted, despite the certificate not being trusted... That's a bug. There's a distinct difference between an untrusted certificate and no TLS/SSL at all.

Append:

On that same token, the cause for the distrust was not made clear. In the past, I think it used to be much more clear. Instead, it was almost like facts about the certificate were not even revealed because it wasn't trusted.

Which is well and good. Untrusted certificate, you can't be sure that the connection is secure. However, if the facts about the certificate and failure are hidden then a man-in-the-middle could intercept, fail certificate verification, and appear the same as the legit site. An expired certificate should be loudly proclaimed by the browser, but it should not be as loud as no encryption at all or a completely unverified certificate.

MITM, maybe not. But side trivia: I can definitely attest that EVERY PUBLIC IP and port is regularly port-scanned and if anything replies, it is attacked (even on non-standard ports like RDP on a port other than 3389).

Absolutely! Basically anything that's not brand new and has open ports... is pwned. [edit] SQL on any port? Pwned. RDP on any port? Pwned. Even with strong passwords, you'll see non-stop password attempts in your logs. And there's no guarantee they won't use an exploit and go "around" the password. [/edit]

I'd love to figure out how they do portals and combine that. So like, you go through a certain port, ask tell that port (over SSL) your credentials, and THEN, attempt to login through a specific port. And the server would only accept incoming requests on ports from known IP addresses, after being verified on the "gateway/portal" IP.

But how could you integrate that with other programs? Easy to make yourself but random program X, automatically making a request to the right portal.

... Maybe a virtual net driver could do it automatically? That, or I guess requiring to connect through a VPN first would count. And the VPN wouldn't actually get you "inside" the network like a traditional VPN. It would just get you to the main "external" services.

I can't stand to browse the Web on a phone. I'll do it rarely if I'm desperate, but it's a miracle that I haven't thrown my phone across the room doing it. I don't know how people do it. Especially IT people.

I have not. Link?

XML looks broken, but the embedded version seems normal, as do the links. Unless maybe the links should not be scaled?