|
Methanar posted:why would you want more bsd-tier binary incompatible reject platforms to split market share, features, tools and patterns across for much the same reasons that i'd like there to be more than one browser vendor, and that i'd like the internet to not just be four websites
|
#
¿
Sep 25, 2020 16:38
|
|
|
|
| # ¿ Apr 23, 2024 19:59 |
|
|
mystes posted:That reminds me, nothing has actually come of the talk about restricting tlds that cas can issue certificates for (so national cas can't issue certificates for .com and stuff), right? you can put CAA records in DNS that CAs must honor, which restrict what CAs are permitted ot issue for those DNS names. i forget if they apply to every name under a record or just the name itself (i.e. does a CAA record on foo.com apply to all of *.foo.com) and i have a strong will to live so I'm not going to go read the BRs this morning
|
|
#
¿
Oct 15, 2020 16:32
|
|
|
PCjr sidecar posted:security theater isn’t just the airport tsa there's a lot of drawbacks to procedures like this but i wouldn't dismiss it all as "security theater". There's a lot to be said for keeping root secrets offline, in an unclonable hardware token, so that you can monitor physical access to the secret with a safe, cameras, etc. it's pretty standard practice for protecting root keys for certificate authorities, firmware signing, all sorts of stuff. k-of-n secret sharing helps prevent scenarios where a single defector can compromise the entire system. the problem in my experience is that usually nobody but the security team takes this stuff seriously. it all depends on each security officer taking their responsibilities very seriously and reviewing what they're being asked to sign or approve and so on, but when I was doing processes like this, our counterparts on the embedded engineering team (for instance) just treated it as a formality, and would just be waiting around in the key ceremony room until we told them "ok now enter your password half on the airgapped machine" and I'm pretty sure we could have gotten them to sign absolutely anything we wanted. and in the best of cases it's a massive pain in the rear end doing dual controlled anything because now you can't even release firmware without scheduling a whole ceremony, and you gotta find time on everyone's calendar, and nothing _ever_ goes smoothly in the key ceremony room (because the actual ceremony machine is airgapped, so you can't test your ceremony scripts on it and oh whoops turns out it's running 32 bit CentOS 6 so none of the tools you brought with you work) so it always goes long past the 45 minutes you booked and aaaugh.
|
|
#
¿
Nov 21, 2020 00:09
|
|
|
Chris Knight posted:tabarn.ac câli.sh
|
|
#
¿
Feb 2, 2021 04:01
|
|
|
go play outside Skyler posted:and maybe open up their api so it works with chrome or something ffs the API for the keychain is "open" in the sense that you can link Security.framework and read/write items... if your app is signed with the right entitlement. AFAIK the reason desktop Chrome doesn't use iCloud keychain is because Apple won't grant the relevant entitlement(s) to apps unless they are distributed through the Mac App Store and Google doesn't want to distribute Chrome through the MAS. and they're quite right. for one thing it would make their nearly automatic update story impossible and for another the mac app store loving sucks and neither users nor developers want anything to do with it.
|
|
#
¿
Feb 17, 2021 17:10
|
|
|
Buff Hardback posted:you can use icloud keychain on windows in chrome, but no such luck on mac yeah i came across that and found it kinda surreal that Apple has enabled this on Windows but not on the Mac: they ship a whole bunch of iCloud bullshit on Windows to enable various iTunes features, and I guess they're not as picky about which processes can read the keychain on that platform. still, loving weird that the Apple user experience should be better on Windows than on macOS.
|
|
#
¿
Feb 18, 2021 03:59
|
|
|
Subjunctive posted:apropos rewriting in Rust the C bindings for `rustls`: https://github.com/abetterinternet/crustls `curl` merged in a TLS backend that uses crustls 10 days ago: https://github.com/curl/curl/pull/6350 the mod_tls stuff is also using/will also use crustls to integrate with apache.
|
|
#
¿
Feb 19, 2021 21:33
|
|
snipe
|
Achmed Jones posted:the california app doesn't even exist for iphone - it's just instructions on how to enable exposure notifications additionally the ENX system used in California, Maryland, Virginia, Washington (state), Washington (D.C.), Wisconsin, New Mexico, Connecticut, Utah, Massachusetts, Hawaii, Colorado, Louisiana and Missouri uses a privacy-preserving aggregation mechanism deployed by ISRG (who run Let's Encrypt), the MITRE Corporation and the National Cancer Institute to report how many exposure alerts have been displayed and other EN telemetry to public health authorities without ever revealing any individual's data
|
|
#
¿
Dec 30, 2021 19:24
|
|
|
I'm surprised that this rate limiting feature should be implemented in the driver, since the card can't defend itself from a malicious driver. Maybe I just don't understand how video cards work. I get that programs on the main system are pushing over little programs for the video hardware to execute (e.g. shaders) but surely there must be firmware or a wee little OS, signed by nVidia, that runs _on the card_ and manages the execution of these programs, the same way any modern SSD has its own firmware?
|
|
#
¿
Mar 3, 2022 17:53
|
|
|
Shame Boy posted:i think when people say "drivers" that includes firmware since it's not like you're downloading card firmware separate from the nvidia drivers or anything, it's all loaded automatically ok yeah, interesting, and having now read TFA I see the key here is that *nVidia* themselves accidentially released the "driver" that removes the mining rate limit, so that could have been signed. Sounds like they are lacking a firmware revocation mechanism, which admittedly is (1) a motherfucker to implement and (2) to be used very carefully even if you have it. haveblue posted:the catch is that you don't want to rate limit under legitimate use, just when crypto mining is detected. maybe that's too tall an ask for the on-card firmware IIRC they don't get all that clever about detecting crypto mining workloads, they just universally throttle the card so that it can do enough matrix math (or whatever) to be usable for graphics applications but not enough to be competitive at mining. I do buy the claim that they would have more context to work with in-kernel than on the card, though. I'd love to learn about mining detection heuristics. I hope it's not like in the old days of benchmarking when they'd check if the running executable was `quake3.exe` and turn on extra (unsafe?) optimizations.
|
|
#
¿
Mar 3, 2022 18:01
|
|
|
changing the hash algorithm also just enters the miners into an arms race with the GPU vendor, and the miners are not likely to win. To change the algorithm, the miners have to do a bunch of theoretical work to prove the soundness of an alternative hashing algorithm that matches the properties of the existing system while evading the GPU's detection heuristics. Then they have to get the whole community to agree to the change. Then they have to implement and deploy it across a significant number of organizationally distributed and presumably highly heterogenous deployments of miners. Presumably also there's some complicated backward compatibility or chain migration work you'd have to do that I don't understand (miners and chain verifiers would need to know about both hashing algos right?). in the best of circumstances crypto agility is loving hard. It'd be miraculous if this were achievable in months and not years. The GPU vendor just has to analyze the new algorithm, update their deny-list and ship that to their hardware. admittedly the miners could just block their GPUs from getting the relevant firmware or driver or w/e update, but any new hardware from the vendor would ship with the updated deny-list and rollback should be impossible. This is a huge asymmetry in favour of the defender. the miners could also play obfuscation games to try to hide the new hashing algorithm from the GPU vendor but I don't think it'd work particularly well. At a minimum crypto communities would surely balk at closed source and confidential hashing implementations. Anyway I'll let the Arxan sales reps advance that argument further, IDGAF enough to spend more time on the idea.
|
|
#
¿
Mar 5, 2022 18:52
|
|
|
lousy hat posted:now that Okta's come out and said "nothing to see here," I guess eventually we'll see if they're right or if their company stops existing this will be an interesting test of this thesis: https://swagitda.com/blog/posts/markets-dgaf-about-cybersecurity/ Maybe the reputational damage will matter more to a security vendor than to say Equifax.
|
|
#
¿
Mar 22, 2022 16:43
|
|
|
FlapYoJacks posted:I had a client yesterday decline adding a TPM to their board. They are going to store private keys forever on the filing system. It’s easier they say. they're not wrong, it is going to be easier. in the same way that not shipping a product is easier than shipping one, but they're not wrong.
|
|
#
¿
Apr 22, 2022 17:54
|
|
|
listen, it's not reasonable to expect OpenSSL to test on every esoteric, niche arch under the sun. What even is this "x86_64" thing anyway?
|
|
#
¿
Jul 6, 2022 00:28
|
|
|
Subjunctive posted:I trust curl too, but they think there’s room for improvement which is why they’re replacing some parts of it with Rust components I'm not sure "replacing" is the right way to think about it. curl is adding optional backends for HTTP (using the hyper crate) and TLS (using rustls), but that doesn't mean they're throwing away the other backends (curl supports a good half dozen different TLS implementations). This would be a non-starter for distros that don't have Rust toolchains in their build system.
|
|
#
¿
Oct 5, 2022 21:43
|
|
|
don't get me wrong, I'm not arguing against deploying Rust components. it's insane that everything in the world is taking untrusted input off the network and handling it with OpenSSL and nginx, all that poo poo should be written in something memory- and threadsafe ASAP. but it's just not possible for a project like curl to use Rust by default, yet. even in the kernel, the Rust stuff is an option. I'd bet that it'll be quite a few years before it's impossible to build kernels without a rustc, so long as you opt out of newer, safer drivers.
|
|
#
¿
Oct 7, 2022 03:50
|
|
|
Subjunctive posted:Microsoft pushed for EV as a way to deal with fraudulent sites getting DV certs. when I suggested/yelled that they should just revoke those certs, they said that there were contractual commitments around certs and they would get sued, which I made clear that I didn’t care about. opera at one point had like 3 locks, it was untenable. eba(some Cyrillic poo poo that looks like a y) was going to ride fortunately the EU is bringing back the glory days of EV with eIDAS and QWACs so you'll get to have those asinine arguments forever.
|
|
#
¿
May 6, 2023 02:48
|
|
|
Subjunctive posted:another kind of secfuck: a 9.8 CVE for a trivially-safe memory leak in a tool that is not designed to handle untrusted input (and is explicitly documented as such) most shocking to me is that there is still anyone at Oracle working on Solaris. I thought they got RIFed away five years ago.
|
|
#
¿
Jun 23, 2023 17:56
|
|
|
Subjunctive posted:well, they imply that their customers can’t because they’re all doing manual management of certs, which is certainly plausible (and likely for EV since I don’t think there’s a way to automate issuance of them yet? loving EV, I should never have gone along with it) there’s no yet, automating EV issuance is impossible by definition. EV CAs are required to verify things like whether a subscriber is an authorized representative of some entity like a corporation or a government. that’s not something you can write an rfc for and automate the way that you can for verifying control of a DNS name for DV.
|
|
#
¿
Mar 16, 2024 06:52
|
|
|
Wiggly Wayne DDS posted:other than here not really we other heard about it due to Winkle-Daddy too what, are you not excited about standardizing RSA/ML-KEM hybrids? cause i'm loving stoked
|
|
#
¿
Mar 18, 2024 19:38
|
|
|
the google ryan notorious for executing dishonorable CAs left Google a while ago and doesn't do quite as much PKI cop stuff anymore. he's been replaced by a different ryan at google. not to be confused wiht that other prolific web PKI ryan who recently got laid off from pki.goog.
|
|
#
¿
Mar 19, 2024 21:44
|
|
|
Captain Foo posted:so i have to assume that the ryan who is posting here is talking with his counterparts from ms and apple on the ca/b and figuring out if/when they’re going to untrust the Entrust root, if i have my understanding of the governance correctly? cab forum is a bit of a sham. the real power is entirely in Google’s hands because 80-85% of relying parties (clients) on the internet use their root program’s (chrome’s) trust store. nobody really cares if MS edge or even safari still trust a cert if chrome kills the ca that said the specific individuals that Google sends to cabf have been cool about it, are good about coordinating scary changes with other root programs and wield their astonishing power over the internet reasonably well but let’s not kid ourselves, cabf’s power structure is about as fair and democratic as the UN Security Council
|
|
#
¿
Mar 20, 2024 18:19
|
|
|
i honestly don't know if Entrust will get pulled, because just as relevant as the magnitude of Entrust's violations is the question of where Entrust certs are deployed. people like to think of a bad CA getting nuked as a simple matter of chome going "get rekt loser" and yanking the root, but it's such a monster pain in the rear end for the browser vendors. if you yank the wrong CA, then suddenly the entire nation of Sweden can't file its taxes anymore, and the bug reports and support calls about that go to the browser, not to the CA or CABF. so browsers wind up having to rig up these complicated partial trust schemes, where they allow list certain intermediates, or only distrust end entity certs issued after some date, or whatever. that's a bunch of new code in security.framework or in chrome and edge that nobody wants to write, QA and ship. the upshot is that the root programs, who once again are the exclusive holders of the actual power to enforce CABF policy, have a strong disincentive to actually distrust roots. so IMO it's possible that they want to just publicly shame Entrust into getting their poo poo together. the less cynical way of looking at this is that CABF can be quite forgiving of misissuances and other errors, so long as the CA that made mistakes is transparent, does robust root cause analysis and commits to substantial remediations on an unambiguous timeline. And that's good! mistakes will happen, and it's better to create a culture where everyone can learn from them and do better than a draconian culture of harsh punishments.
|
|
#
¿
Mar 20, 2024 18:39
|
|
|
Subjunctive posted:IME those go to the sites (or in-house IT for corporate use) and only in very low volume to the browsers, because nobody really understands how it works, but the Government of Sweden would certainly be working some management chains yes, excellent points. though the fact that the end user has no means of appealing these decisions that are being made out of concern for their safety is also a bad outcome of the Pax Chromium, IMO Captain Foo posted:To me, the more egregious thing than than the missiuance itself is the doubling down and submitting a non retro change request instead, and then not being able to find all their certs. It does seem like a huge pain but I’m not in business as a CA either it _is_ a huge pain, and in particular the way that CABF/m.d.s.p will follow up on promised remediations creates complex incentives for CAs disclosing incidents. you want to make sufficiently substantial and specific commitments that the forum will trust you again, but not so much that you now have to invite ryans@google.com to your engineering team's weekly planning meetings so they can check up on whether remediaton item 2.(b).1. is on track to go live by next month. the other thing is that if a CA ships something as an incident remediation, then they can't turn it off again without giving CABF a chance to chime in. needing ryan's permission to clean up tech debt sucks!
|
|
#
¿
Mar 20, 2024 18:58
|
|
|
we should replace the Chrome Root Program with the CHOAM (Certificate Honnete Ober Advancer Mercantiles) Root Program
|
|
#
¿
Mar 20, 2024 19:17
|
|
|
Subjunctive posted:not sure about Safari, they generally do all that stuff at the OS level IIRC safari trust evaluation is handed in trustd, which comes in the OS. the same path builder/trust decider is used by anything in the OS that uses apple APIs to establish TLS sessions, including I think the openssl that Apple ships. they can deliver updates to the root trust store, trusted CT logs and I believe revocation lists out of band of OS updates. on your phone hit Settings -> General -> About -> Certificate Trust Settings and you can see the version of the currently installed trust store
|
|
#
¿
Mar 20, 2024 19:23
|
|
|
the bits of Firefox on iOS that render html and run JavaScript are “just safari” (this may change because yada yada yada European Union) but moz can still write loads of code around that to do things like passkeys
|
|
#
¿
Mar 22, 2024 22:33
|
|
|
the Python or js debate is irrelevant to software supply chain. even if you (incorrectly) believe that proving the integrity and provenance of a .py file is substantially different than proving that of a compiled binary, you still have to solve the integrity+provenance problem for the binary of the interpreter you use to run the .py and .js files, and the libc the interpreter links, and the pid 1 that supervises the interpreter, and the kernel it runs on top of, etc.
|
|
#
¿
Mar 24, 2024 21:05
|
|
|
haveblue posted:aaaaand now we’re on trusting trust we’re not, necessarily. trusting trust is hard but security nihilism should be rejected outright (n.b. I am not accusing you of being a nihilist). nothing about code integrity or software supply chain is easy, but it isn’t impossible. several robust and viable solutions for authenticating executables, config files, scripts and other kinds of content have been shipping in hugely popular and successful systems and providing meaningful protections for decades now. code signing is real, it’s strong, and it’s your friend.
|
|
#
¿
Mar 24, 2024 22:36
|
|
|
post hole digger posted:wanted to get an up-to-date answer here, but what is the thread opinion on dnssec as a website owner (turning it on with your own public nameserver provider) don’t do dnssec unless you have to for some compliance reason. Google “Thomas ptacek dnssec” to learn why. the dns technologies that meaningfully complement https are DNS Over TLS and DNS Over HTTPS and Encrypted Client Hello. these are worthwhile and inasmuch as you can as a server operator, turn them on actually ECH has little to do with dns but you know what you can s my d use it anyway
|
|
#
¿
Mar 26, 2024 01:35
|
|
|
EV would have to be harder to deploy. renewing DV just means letting certbot or caddy do its thing and you never look at it. renewing EV means you have to, I dunno, get a new notarized letter from your jurisdiction's authority on incorporation attesting to the fact that you are in fact Fartbutt GmbH.
|
|
#
¿
Mar 26, 2024 15:13
|
|
|
FB messenger just did a really nice talk about the E2EE rollout at Real World Crypto. https://iacr.org/submit/files/slides/2024/rwc/rwc2024/71/slides.pdf IACR should have the video up any century now
|
|
#
¿
Mar 29, 2024 15:05
|
|
|
why is windows broken out by version but there’s just one big android bucket?
|
|
#
¿
Apr 5, 2024 00:17
|
|
|
|
| # ¿ Apr 23, 2024 19:59 |
|
|
what you're doing is doable but risky, because I think you'd encounter lots of impedance mismatches between the deployment and threat models assumed by the web PKI and what you'd be doing in your code signing scheme. for example, a Let's Encrypt cert is valid for 90 days, and that could go down to 10 in the future (inshallah). in the context of TLS, short lived certs are cool and fine because the server signs handshakes with a brand new cert all the time so you get liveness. but what would it mean if i get your binary 100 days after you signed it? do i just ignore leaf expiration? now you're not operating under the same trust model as TLS/web PKI and I think you'll eventually encounter Problems if all you care about is an attestation that the binary came from the domain owner, then you achieve exactly the same thing by delivering an unsigned binary over HTTPS from the domain. or, you serve a SHA-256 of the binary from the domain and allow the large binary to be served from arbitrary sources.
|
|
#
¿
Apr 10, 2024 17:00
|
|