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.
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.
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.
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).
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.