pfg

48 ms·

421.
by pfg 10y ago
I've thought about building an IA.BAK extension for typical NAS software like Synology's DSM, QNAP's QTS, etc. Unfortunately, I've found that these platforms don't come close to the developer friendliness we've
422.
by pfg 10y ago
You spelled Wi-Fi wrong. :-) On a more serious note, I haven't had any issues on my 13" MBP with an integrated GPU. Here's hoping this'll be fixed by the time my 15" MBP with a discrete GPU ships ...
423.
by pfg 10y ago
Browsers do have mechanisms for filtering out known phishing (or malware) sites (e.g. Google's Safe Browsing (used by Chrome, Firefox and (IIRC) Safari), Microsoft's SmartScreen). Guessing based on the domain (without having any a
424.
by pfg 10y ago
Practically speaking, this has no impact until browsers start requiring CT (which is in about a year for Chrome).
425.
by pfg 10y ago
> There are potential security concerns. Suppose Let's Encrypt has a vulnerability other certs don't, or their chain is compromised somehow, this could put people at risk without them knowing it. Could you describe what kind of
426.
by pfg 10y ago
I like to think that this is the right approach, especially for shared hosting environments (which is what this announcement is about, presumably). These site owners already trust OVH to host their sites and to hold the private key for a ce
427.
by pfg 10y ago
To be fair, that's true for just about any password manager unless you audit the code and use reproducible builds. It just tends to be easier to place these kind of backdoors in web apps because the code is basically re-downloaded each
428.
by pfg 10y ago
OEMs pay for those Windows licenses, that's definitely not what anyone would call "free". It's like saying CPUs are effectively free because the vast majority of users got one with their purchase of a PC. Sure, you didn&
429.
by pfg 10y ago
The public key infrastructure in modern browsers allows you to use HPKP, which gives you all you need in order to fully control that a message can only be read by its intended recipient, if you need that level of assurance. (Yes, it's
430.
by pfg 10y ago
> But I think it'd be a tough sell to any business to have their users presented with a certificate error message for up to four days because Globalsign screwed up. Are you making the argument that a business would want the ability
431.
by pfg 10y ago
That was discussed here, starting with [1]. tl;dr: Too many broken sites out there, and this kind of opportunistic encryption doesn't hold up in any adversarial threat model (MitM blocks :443 and forces downgrade to :80). [1]: https:&
432.
by pfg 10y ago
> There's a one smoldering on in Germany[2], but it's getting almost no press - most probably because Google are suppressing any mention of it in their results or in Google News (Crazy? Maybe, but you can't disprove this e
433.
by pfg 10y ago
This begs the question: Where do you draw the line between "data logging" and submitting the URL (or domain, I'm not certain on what level WoT would normally operate) to a server in order to get its reputation? In the end, yo
434.
by pfg 10y ago
Unfortunately, that would break a large number of sites out there. Some serve different content (as in: not what the visitor would be expecting) on HTTPS, many would have mixed content warnings, etc. Just take a look at the ruleset used by
435.
by pfg 10y ago
That's a good point, and exactly what Chrome is planning on doing[1]. Firefox has a similar feature for HTTP-only sites using password fields (I think it's currently enabled in Firefox Developer Edition). [1]: https://s
436.
by pfg 10y ago
That's why preloaded HSTS exists - basically a list of domains included in browser binaries that those browser will only ever visit via HTTPS.
437.
by pfg 10y ago
Ignoring the price tag, there's no difference between Let's Encrypt and "other old CAs". They both perform the same kind of validation for DV certificates. Some might even say Let's Encrypt does more than others, gi
438.
by pfg 10y ago
The common solution to this problem is to deploy a HTTP(S) proxy (like Squid) for outgoing connections. These can operate based on things like the Host header rather than the destination IP. Your web server would be locked down to only allo
439.
by pfg 10y ago
FWIW, both of these issues are acme-tiny-specific quirks. The protocol allows clients to handle both intermediate certificate changes and ToS updates without any user interaction (and without breaking renewal). These things were not impleme
440.
by pfg 10y ago
This might have made sense a couple of years ago, but I don't think desktop hardware is advancing at a rate where yearly updates are a must. This seems even more true for typical Mac use-cases where users don't quite care as much
441.
by pfg 10y ago
> - No iMac update (!!!). iMacs were refreshed in late 2015. It's typically ~3 years between new generations, often with a hardware refresh somewhere in between. Nothing new here. > - No monitor announcement. They partnered with
442.
by pfg 10y ago
Local trust anchors have never really been something that CT concerns itself with, and I don't see that changing. For local/internal CAs, nothing is changing with this. Only certificates chaining up to a publicly-trusted root are
443.
by pfg 10y ago
Yes, both keys can be used to revoke, so as long as you still have either the account key or all certificate private keys, you're good.
444.
by pfg 10y ago
Again, this isn't about tokens. We're talking about a private account key (like, an actual RSA or ECC key), which is associated with FQDNs for which the holder of an account key has the ability to issue certificates. I'll try
445.
by pfg 10y ago
This is not a traditional token use-case (as you would use for e.g. a password reset email). We're talking about long-term identity keys (the account key) which are associated with authorizations for FQDNs, giving the owner of that key
446.
by pfg 10y ago
Haven't you heard, you can solve any problem by throwing a blockchain at it! ;-) On a more serious note, Certificate Transparency, which will become mandatory in Chrome in about a year, uses technology that is strongly related to block
447.
by pfg 10y ago
I think it's 36 months right now, but that's a Baseline Requirements thing, Let's Encrypt can (and does) use shorter periods. 36 months is the upper limit for all CAs. Let's Encrypt currently uses 90 days, and will go to
448.
by pfg 10y ago
With the stolen account key scenario, you still get an audit trail through Certificate Transparency, as Let's Encrypt logs all certificates they issue.
449.
by pfg 10y ago
No, account keys are typically persisted and re-used, though specifics depend on the client implementation. I still think this is largely a non-issue. If you compromise the target system, you can just keep stealing private keys as they are
450.
by pfg 10y ago
Yeah, it's definitely something I'm hoping the CA/B Forum will address at some point. Something like a month seems like a sweet spot between not being annoying for new customers when they're in the process of getting mul

More ›