dc352

technology building blocks are rarely a problem. The problem is to scale it up.

Akamai certificate renewal with a couple of Lambda functions running in AWS. We have built this as a tool to help us and wonder if there are more people who would find it useful.

... and we'now fixed a CORS issues that caused some problems to pull the list of test servers :(

The only way to do it (I'm lazy so didn't read any of the documents - my gut feeling of an engineer) ... is to use ECDH, which provides EC params in ServerKeyExchange. CryptoAPI might have used those and just pull the public key from the cert.

I suspect you're overcomplicating the attack with all the math and we can ignore most of it.

The only way the attacker can tell the MS Crypto API is via the TLS protocol. You can only do it if it's relevant. The only option for that is to use ECDH, which allows the server to supply EC parameters for the Diffie-Hellmann exchange.

My bet is that the problem is that MS Crypto API took those parameters as correct without checking them against what's in the certificate. I.e.,

ServerKeyExchange - here's the EC spec, we just need the public key Certificate - ah - here's public key, we have the ECparams - let's run the math

:)

our disks in London went down at about 8:45pm UTC (10 mins 100% disk utilization alert triggered at 5 to) and DO recovery message was sent out at about 2am UTC. We switched our service (keychest.net) on at 3:15am

that would be pretty cool but to have that, you need a high-network-latency solution, i.e., pretty much cold back-up. For some time I thought it's pretty last century option but having been experimenting for some time now, it's the option with lowest impact on system performance. More importantly, it's reasonably resilient.

That wouldn't be at the top of my list. We have "Volumes" for databases and they were inaccessible for like 6 hours. I don't think any DNS is involved in mounting these. But hey, there's always a lot of crap hidden behind the scenes :)

We are still looking into it and I’m in touch with DO and I hope to learn more from their support. Unfortunately, their response time is currently around 2 days.

I guess my point here was that Our database should be resilient to this kind of infra issues and ideally self-heal if these are transient events.

You can test yourself at https://beta.keychest.net

If I get it right, you should be able to see your email server (if it uses TLS - we don't support StartTLS atm.), if you add it to the list of servers as, e.g., my.email.server:465

We want to simplify adding servers with multiple services. The plan is to allow setting a list of ports to check per server.

... or is it a part of a grand scheme to return back to blackhat roots?

If you trust your smartphone then you don't necessarily need smartcards. But if you want to run own applications in a trusted environment then JavaCards are really nice. You can also use them as a portable trusted "computer", wallet, ...

In terms of use, there's an additional complexity for using JavaCards. We try to solve that a) making the code easier to port and b) providing access to smartcards via TCP/IP where it makes sense to have them in a rack.

In general, they don't run out of battery and you can print your headshot and name on them.

In terms of "hardware" - all chip debit/credit cards use the same processors (actually they are a complete computers with EEPROM, RAM, co-processors).

Can I attribute this to a particular name?

It is an interesting one - here is the original source (and there were many more mentioning 300 days).

https://community.letsencrypt.org/t/dns-authorization-lifeti...

It is from 14 June 2016 (a few months back), @pfg states "The CA/B Forum is currently developing new rules for domain validation and is probably going to settle on a validation period that is significantly longer than the 300 days currently in use ..."

Is there an authority to say which way it will go?

So do you imply that the account key is created from scratch for every new certificate?

Why we were surprised (and we don't say the implementation is necessarily wrong!) is that I can use the account key anywhere. If the genuine user keeps refreshing authz's, it will keep the stolen account key operational as well.

That's my understanding. I may be wrong, but if so, I don't quite yet understand the logic behind authz.

The difference is that I need to access your file system only once to get your account key. I need permanent access to exploit your automation.

Attackers can also scale revenues, potentially, by selling account keys to third parties.

I've updated the blog post. I don't think, though, it has any material impact on the rest of the text.

Bugger. Thanks!

My last comment was towards key generation, not curves. Bug as I said, I am not in a position to say what the impact is.

My err - rubbish wording as I was thinking primes and talking curves.

Still, while I'm punching here a wee bit above my weight - I should read the 186-4 again - there are some tests to verify the strength of the prime. Is it enough for a similar classification? - I don't know...

ECDH doesn't give you authenticity, i.e., you can't get a certificate for that.

When you look at ways to generate ECC keys, there are classes of vulnerable numbers for which you need to test.

I don't say switching is a bad idea but not sure it would prevent this kind of attack :)

A short discussion on my blog: https://www.dancvrcek.com/re-investigating-the-origins-of-rs...

Not quite the answer, but well spotted! It still seems to be just KMS - we can do crypto operations in secure hardware as well.

Thanks!

We are trying to figure out if there are people out there who need cloud HSMs. Do you have a project, looked at Amazon CloudHsM but can afford about 1/100th of the cost or less? We are geeks in a startup and need help!

We built cloud HSM; EnigmaLink to show it off - give us hard feedback! Please.

It's not completely custom - trusted elements have independent evaluations (FIPS / EAL). We think that a combination of local and centralized elements provides best security.