The jabber.ru post referenced here presents clear evidence (in the section titled "Network") that the malicious actor was able to reroute traffic going to the legitimate jabber.ru server. An attacker in this position does not need an RCE to get a cert, they can just get one issued the normal way, because they do effectively control the IP address that the domain is pointing to.
One suggestion for anyone concerned about this weakness. You can use the CAA record to pin the domain to a specific certificate authority, issuance method, and account. This is imperfect, as CAA record validation (edit: of CAA extensions) is not mandatory yet. But by March 2027 all the CAs a supposed to have support.
Sprinkle some DNSSEC on the CAA record too, if you'd like.
Just be careful, if you host your DNS at Cloudflare (maybe others?), they will rewrite your CAA record[0] if you use TLS with them. This is in the name of convenience but it was surprising when I first learned.
CAA checking is mandatory, so you can always restrict to a given CA.
To get complete control with DNSSEC, you also need the accounturi and validationmethod extensions (which you need to guarantee only your account can issue, and only with the DNS validation type).
Those aren't yet mandatory, but you can restrict to a CA today which implements them, like Let's Encrypt.
Even without DNSSEC, the CAA record approach can help, as it requires MITMing between the CA and the DNS server, which may be harder in some cases than just MITMing a target site.
If your DNS isn't working, you're not going to be making connections anyway. And if you can't keep DNSSEC running, you can't keep certs up to date either. DNSSEC is actually much simpler, with fewer failure points, once you set it up.
> It is high volume (=it need be cacheable).
It is. Unlike certificates. And the cache lifetimes are much shorter than typical certificate lifetimes.
It is self-evidently not correct that companies that can't keep DNSSEC running can't keep certs running. Entire TLDs have fallen off the Internet because DNSSEC has broken. A certificate never took Slack down for half a day. It's just obviously not true.
It's amazing what practice and investment can do, even for a fragile system like X.509. Yet certs still break constantly. Like permanently killing people's "perpetual" Microsoft Word licenses in a story posted within hours of this one.
That's right, it's easier to setup such MiTM using an intermediate server, because only getting the private key of the certificate won't get you the user's traffic due to PFS.
You either need to disable PFS on the server, or export TLS master keys for each session in some way, or MiTM.
That explains the over-representation of Oceans in NYC’s supercharging network, and one of the worst side-effects of opening that network to non-Tesla operators.
Overall I think it’s a good thing, but it’s the closest to Eternal September I ever experienced in my life, the sudden change inclusion of cultural strangers in a shared space with its customs etc.
> It doesn't provide a useful security feature, but it does lock out competition very well.
This seems to presuppose that service providers using reCAPTCHA are either clueless idiots or actively expending resources and lowering their conversion rates to support the supposed Google/Apple duopoly. That does not strike me as a plausible claim.
Well, they're committed to provide as secure device as possible. There's no love for Google in the team.
They recommend Google play over fdroid due to some security concerns, not because they like the service. The reasoning is available on their discussion forum.
And yeah, it won't officially be supported on other devices than the upcoming Motorola and perhaps the next pixel. Too bad.
It's the only news I've heard about new-phone-tech that's gotten me remotely excited in a long time. I'm too poor to be buying new devices though so I'll have to let others do the beta testing for a couple years.
The requirements are not particularly stringent. It is more an embarrassing show from the rest of the Android OEMs that they don't meet basic standards like timely security updates and a decent support period.
It argues no such thing. Of the 20 instances of the word "interest", 19 are obviously referring to the interest that the IRS will charge you on your balance if you don't pay your taxes by the due date. The one remaining one is this:
> Overpayment interest for the 2020–2023 disaster period.
and refers to the interest that the IRS will pay you if they owe you money (a refund) that they don't manage to return to you in a timely manner.
It mentions "Overpayment interest for the 2020–2023 disaster period" which I figured could be applied broadly, but I guess that was more my interpretation rather than the intention.
The linked website and repository do not refer to the outputs as "verified C++". The use of that term in the submission title here seems misleading, and the Design Principles [1] document clarifies it is only the source (Rocq) programs that are formally verified. It seems far from obvious that the complex and ad-hoc syntactic transformations involved in translating them to C++ preserve the validity of the source proofs.
Well the title of the paper is
>Crane Lowers Rocq Safely into C++
So 'safely' implies somehow that they care about not destroying guarantees during their transformation. To me as a layperson (I studied compiler design and formal verification some.long time ago, but have little to zero experience) it seems at easier to write a set of correct transformations then to formalize arbitrary C++ code.
This is another reason we are being careful with the correctness claim. The closest project I know right now that comes close to a formalized model of C++ is the BRiCk project:
Yes, we were careful not to call it that. I still don't mind calling our programs verified, since they are verified in Rocq and we do our best to preserve the semantics of them. Right now the only measure we have is testing a small set of programs and also carefully picking a subset of C++ that we trust. Our future plan is to generate random Rocq programs, extract them via Crane, and compare the output to the outputs of extraction to OCaml, and even CertiCoq, which is a verified compiler from Rocq to C, (mostly) proven correct with respect to CompCert semantics.
Most of these attack vectors have been known for 10 years, and yet researchers keep finding bugs in major implementations to this day. Here's one from last week: https://portswigger.net/research/the-fragile-lock
> How would you digitally sign a Json document and embed the signature in the document?
You would not, because that's exactly how you get these bugs. Fortunately serialization mechanisms, whether JSON or Protobuf or XML or anything else, turn structured data into strings of bytes, and signature schemes operate on strings of bytes, so you'll have a great time signing data _after_ serializing it.
This seems like a distinction without meaning. The question is whether JSON serializations intended for canonical signing would be somehow safer than those XML serializations. Obviously people would like all the same features that caused problems before.
That is not, in fact, the question. The whole point of storing signatures separately from the serialized bytes they sign is not having to rely on any properties of the serialization scheme. It does not matter whether your serialization is canonical or not if you don't need to parse the document before you've verified the signature on it. XML-DSig, to the contrary, requires that you parse the document, apply complex transformations to it, and then reserialize it before you can verify anything, which is what makes bugs like "oops the canonicalization method errored and now my library will accept a signature over the empty string as valid for any document" (https://portswigger.net/research/the-fragile-lock#void-canon...) possible.
You are saying people shouldn't want what they want and since JSON has no standards for it you assume it won't happen. Not even X509 is interested in working with detached signatures.
> It does not matter whether your serialization is canonical or not if you don't need to parse the document before you've verified the signature on it.
It most certainly does. First or last duplicate key?
I am comfortable saying that, when designing a signature scheme, people should not want features that are known to consistently lead to catastrophic vulnerabilities.
When I look at JSON related crypto, say JWT or WebAuthn, I am (un)comfortable saying the CVE causing complexities are there but repeating and not consolidated on a standard layer.
I'm not sure why you take me for a JSON/JWT fan (I'm happy to agree they've had their own share of implementation bugs), or what that has to do with signature wrapping bugs in XML-DSig, which is what I've been talking about this entire time.
> God forbid you have an accident and you end up at the wrong hospital when the one down the road is in-network but the one they took you to is out-of-network and you wake up owing thousands of dollars.
If you examine the statement of benefits for your plan, you will find that it says something similar to this:
> Emergency Services are covered at the in-network cost-sharing level as required by applicable state or federal law if services are received from a non participating (out-of-network) provider.
> The member is responsible for applicable in-network cost-sharing amounts (any deductible, copay or coinsurance). The member is not responsible for any charges that may be made in excess of the allowable amount.
You’re right. The No Surprises Act did make this a lot better. However it still doesn’t cover ground transport (and specific state laws do in some cases.)
Additionally for post-stabilization care the hospital is going to shove a lot of papers in your face and they’re probably not going to tell you that one of them is the one that says you agree to pay to whatever those services and waive your protection against balance billing. Yes they’re supposed to present it on its own and with your full consent and yes you can dispute that but people sign the forms and then still get screwed.
reply