pfg

48 ms·

451.
by pfg 10y ago
Why not? Right now, compromised account keys give you the ability to issue certificates that are valid about as long as certificates are valid (or, in the worst case, +90 days from the original expiration date). Just about any scenario wher
452.
by pfg 10y ago
Revocation is also possible using the certificate's private key, but I agree that the risk of keeping the account key is not worth the hassle of deleting it straight away. As it stands, authorizations are valid as long as certificates,
453.
by pfg 10y ago
> I did expect that each request includes a fresh verification of the domain control. And I also expect that substantial majority of people out there believe in this process / data flow as that’s how certificates have always been ve
454.
by pfg 10y ago
IIRC they were revoked in the course of the investigation (somewhere in the last two months). That being said, the risky bit is that they actually signed those SHA-1 certificates in the first place - a certificate that could be specially cr
455.
by pfg 10y ago
It remains to be seen whether they will actually hold the private key for that intermediate certificate and issue end-entity certificates from it, or if this is just some sort of reselling deal where a different, trusted CA holds the key, p
456.
Background for 1Password 4.6.1 Security changes(discussions.agilebits.com)
2 points by pfg 10y ago|0 comments
457.
by pfg 10y ago
This is only for publicly-trusted CAs. I'm not aware of any plans for local CAs, and I don't think it would make sense to require CT for them.
458.
by pfg 10y ago
Browsers will make their own policies regarding which log servers they'll trust, similar to the CA system. Google's policy for log server operators is documented here[1] and is fairly strict - a number of third-party log servers h
459.
by pfg 10y ago
No, that's not a valid conclusion. Browsers do not query log servers in real-time whenever they see a new certificate. Rather, servers send SCTs which are "a promise to add the certificate to the log within some time period"[
460.
by pfg 10y ago
For Chrome, the policy is that you need to deliver SCTs from a certain number of trusted Google- and non-Google log servers. These can be cryptographically verified to have been included in those logs. There's no real privacy issue bec
461.
by pfg 10y ago
I suspect that this would be a "perfect is the enemy of good" type of situation w.r.t. native apps. Key pinning is certainly the preferable solution for native apps, but defaulting to at least the security properties provided by
462.
by pfg 10y ago
Baseline Requirements also allow domain validation via DNS or a HTTP request. Essentially all domain validation methods break down once you're in a position to MitM the CA.
463.
by pfg 10y ago
> the browser has to download the missing intermediate if it's not already present in its cache Note that not all browsers support fetching the intermediate certificate if it's missing (one example being Firefox), so visitors m
464.
by pfg 10y ago
This seems to be due to an incomplete certificate chain, which is probably also the reason why Comodo's SSL Analyzer says the certificate isn't trusted. Only browsers that have previously cached the intermediate certificate (or th
465.
by pfg 10y ago
Another reason why someone might pick Caddy over nginx or apache is to get rid of OpenSSL (and forks). Go's TLS stack is generally considered to be one of the better TLS implementations out there. Despite not yet having received the sa
466.
by pfg 10y ago
That's why "badidea" exists.
467.
by pfg 10y ago
Google open sourced their server implementation[1]. The problem that a number of CAs and other log operators have run into is that Google has rather strict requirements[2] for uptime and such (which makes sense!) if SCTs from that log serve
468.
by pfg 10y ago
> I must say though, I'm increasingly frustrated by software vendors trying to strip away control over our own machines. I get the sentiment, but if you look at how common malware is on Windows versus (walled-garden) platforms like
469.
by pfg 10y ago
The original plan[1] was to distrust both WoSign and StartCom after a certain date. Shortly after that, Mozilla met with representatives from Qihoo, WoSign and StartCom, and considered the possibility of treating StartCom separately under c
470.
by pfg 10y ago
Sounds about right, but one thing to keep in mind is that "Removal of root" is only one possible route Mozilla can go for. They could also revoke (root or intermediate) certificate(s) through OneCRL, and while I haven't tried
471.
by pfg 10y ago
SHA-1 is fine in this context. SHA-1 isn't as collision-resistant as it was once thought to be, but that's not a property that you care about for this use-case. The same principle applies to checksums that are sometimes published
472.
by pfg 10y ago
"They" most likely being actual users flagging the submission, as happens often with political stories.
473.
by pfg 10y ago
Efforts like Certificate Transparency and HPKP solve most of these issues and do not require a full replacement of the Web PKI.
474.
by pfg 10y ago
> As far as I know this asked blog post was never published and then Apple realease it's response. From the blog post: > Update: Just to make it clear, I have complied with Apple’s request and have sent a blog post draft approxim
475.
by pfg 10y ago
> Both were faulty and they obviously didn't come to an agreement. I don't know how you arrived at that conclusion. The developer offered to publish a blog post saying that the app was removed due to fraudulent activity on a li
476.
by pfg 10y ago
> They weren't asking the dev to admit to fraud. They were asking him to admit to opening multiple developer accounts and losing control of one. Which both sides acknowledge he did. I'm not sure I understand why the developer t
477.
by pfg 10y ago
The URL being disclosed to Apple was what I was getting at, which would happen with any approach that involves Apple performing the request on behalf of the user. I don't think the trade-off you're describing is necessary given th
478.
by pfg 10y ago
It would also expose any URL you send or receive via iMessage to Apple, whereas messages are otherwise end-to-end encrypted.
479.
by pfg 10y ago
Messages are end-to-end encrypted in iMessage, meaning Apple cannot read the message contents. This solution would require Apple to bypass that encryption for URLs (which are often privacy-sensitive). A good approach would be for the sender
480.
by pfg 10y ago
That's a fairly common vulnerability. A good approach for services that need to fetch arbitrary URLs is roughly: 1. Resolve hostname and remember the response 2. Verify that the response does not contain any addresses in a private IP s

More ›