3 ms·

A script without context or explanation of what it is useful for. Why did you submit this?

patio11 16y ago
That's a neat hack. I once had call to send banking details to a client. It was very annoying - eventually settled on encrypting an emailed zip file and sending password out of band. This, on the other hand, turns any web developer's SSL cert into their PGP key without their advance cooperation. (They don't have to have one, understand why they need one, or create one and publish the public key. They just have to have an https site, like all my clients already do.) Limited utility, since decrypting is impossible for regular people and larger corps would have that private key locked down like crazy, but a very neat hack. I could actually see myself using it, too, for secure geek-2-geek transmissions.
- k00k 16y ago
  Friends of mine have created http://lockify.com/ http://lockify.com/ exactly for the purpose you outline with the banking details.
  - deleted 16y ago
    [deleted]
inaequitas 16y ago
Zed Shaw wrote this (https://twitter.com/#!/zedshaw/status/54434747652390912 https://twitter.com/#!/zedshaw/status/54434747652390912) and then him and Dan Kaminski had a good talk on Twitter about it.
- zwp 16y ago
  Great I think that got most of it (validation!) but revocation checking worries me and a skim of the OpenSSL (0.9.8o) sources doesn't leave me with the warm'n'fuzzies. s_client.c calls SSL_CTX_set_verify() (the default verifier). Results from that can be obtained from SSL_get_verify_result() and are documented in verify(1). All of the CRL/revocation-related return codes there are marked "unused". There is no mention of OCSP. I found found a "crl_check/crl_check_all" option for verify(1). Command line help mentions an "ocsphelper". OpenSSL does have a separate OCSP client. But I don't think any of this machinery is activated by default.
bigiain 16y ago
I thought it was a fabulous (tho limited utility) hack around the key distribution problem.

That's a neat hack. I once had call to send banking details to a client. It was very annoying - eventually settled on encrypting an emailed zip file and sending password out of band. This, on the other hand, turns any web developer's SSL cert into their PGP key without their advance cooperation. (They don't have to have one, understand why they need one, or create one and publish the public key. They just have to have an https site, like all my clients already do.) Limited utility, since decrypting is impossible for regular people and larger corps would have that private key locked down like crazy, but a very neat hack. I could actually see myself using it, too, for secure geek-2-geek transmissions.

k00k 16y ago
Friends of mine have created http://lockify.com/ http://lockify.com/ exactly for the purpose you outline with the banking details.
- deleted 16y ago
  [deleted]

inaequitas 16y ago

Zed Shaw wrote this (https://twitter.com/#!/zedshaw/status/54434747652390912 https://twitter.com/#!/zedshaw/status/54434747652390912) and then him and Dan Kaminski had a good talk on Twitter about it.

zwp 16y ago
Great I think that got most of it (validation!) but revocation checking worries me and a skim of the OpenSSL (0.9.8o) sources doesn't leave me with the warm'n'fuzzies. s_client.c calls SSL_CTX_set_verify() (the default verifier). Results from that can be obtained from SSL_get_verify_result() and are documented in verify(1). All of the CRL/revocation-related return codes there are marked "unused". There is no mention of OCSP. I found found a "crl_check/crl_check_all" option for verify(1). Command line help mentions an "ocsphelper". OpenSSL does have a separate OCSP client. But I don't think any of this machinery is activated by default.

bigiain 16y ago

I thought it was a fabulous (tho limited utility) hack around the key distribution problem.