[cryptography] Client certificates, Tor-exit nodes and renegotiation
Dear all, I have a question regarding TLS, client certificates and Tor Exit nodes. Am I correct in my assumption that when a client connects to a TLS-server, both the server and client certificate are passed in clear-text (clear enough) to the other end before the certificates are validated and the secured connection gets established? If so, does it mean that using client certificates over Tor allows every exit node and system on-route to the server to learn both the client-certificate and the end-point, defeating the purpose of Tor? Is TLS-renegotiation, where the client connects anonymously to the server, validates the server certificate, sets up the secured connection and only then offers to send the client certificate, sufficient to make client certificates safe to use over Tor? Or are there more pitfalls to expect with client certificates and Tor? With regards, Guido Witmond. signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Client certificates, Tor-exit nodes and renegotiation
On 03/14/14 17:48, Tom Ritter wrote: Yes - sending client certificates over Tor will de-anonymize in the same way that sending your real name or username over HTTP over Tor will de-anonymize you. Personally I consider this a flaw of TLS, not Tor, which does not protect the client certificate from either a passive or active adversary. There were some proposals to move client certificates further into the handshake, and protect them against a passive and/or active adversary (depending on proposal) - but they did not have much traction and then Snowden happened and everyone is focused on TLS 1.3. Thanks for confirming. Ironically, lousy password over TLS and Tor are safer than strong client certificates and Tor... It seems that 1.3 addresses this problems entirely. https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf A nit: when you say every system on-route to the server, I assume you mean between the exit node and the HTTPS endpoint, in which case yes. If you mean every Tor intermediate node, then no. Sorry, yes, I meant, from the exit node towards the server. Using TLS-renegotiation to send the client certificate inside an already-server-authenticated channel seems like it would work to me - I have not tried doing it with any library. I'll give it a try. Regards, Guido. signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Client certificates, Tor-exit nodes and renegotiation
On 03/14/14 18:02, Alexandre Anzala-Yamajako wrote: It also might be worthwhile to note that Client certification is not very common and needs an infrasctructure to generate and deploy. Also even if the client certificate is sent encrypted later in the handshake, it's size will be noticeable in the handshake (except if we are ready to pad certificate-less client messages). A competent and funded organization might then have a very small pool of users to choose from as to who might be trying to connect a particular server which somewhat defeats the purpose of Tor That's why I pursue the option of using client certificates everywhere, for everyone. In a way transparent for the end user. Eliminating passwords as a side effect. Regards, Guido Witmond. signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Allergy for client certificates
On 10/10/13 20:12, Michael Rogers wrote: On 10/10/13 09:29, Guido Witmond wrote: It looks like you've worked around the UX issues by inserting an EC-aware proxy between the client and server. Who would be responsible for deploying such proxies? That proxy lives in the end user's computers. Right now, the user needs to install the proxy. I hope to get time and funding to make it a Firefox plug in. I hope that when it proofs useful browsers will adopt it. I hope you manage to persuade browsers to support it, because it seems like it will be difficult to get sites to adopt EA until their users can reliably expect it to be supported on every machine they use. Browser support would be a big breakthrough. (Sorry for referring to EA as EC in my last email!) It's not a trademark or so. As long as it's clear from the context I'm fine with it. :-) My family and friends outside the tech community are quite casual about logging into their accounts from friends' machines, work machines, internet cafes, etc. It's all very well for us to say that's a bad idea, but we can't deny it's convenient to be able to log in from anywhere with nothing but a password. If the computers and browsers were designed to protect the users against many risks, it would not be a problem. However, most browsers are designed by companies that don't deliver that promise. We are slowly getting there with things like sandboxing, partitioning. See qubes-os.org and Genode.org. There is also the cryptostick, a usb/smartcard combo. The first generation can hold only 3 keys. When we have one that can hold a few hundred, it makes it easier. People can carry them along. As each certificate/key only fits one site, the amount of damage is limited to the sites that any malware can reach. And there are ways to obfuscate the name of the site where that key fits. A hash of the sitename, with a simple password as index to the keys. I can definitely see the benefits of EA for users who have a few personal devices that are synced and not shared with other users, and who value the security of using their own devices more than the convenience of being able to log in from anywhere. That describes me, but it doesn't describe most of the people I know. It's a thing that we, system architects/crypto-plumbers need to address. To give a (always flawed) analogy: People expect a Volvo in terms of security when they read the brochure but all they get is a T-Ford. It requires a lot of care to keep it safe and going. I don't blame the people for having these expectations. We need to make it happen. Perhaps you could think of a killer app for EA that appeals to people whose habits match the way EA works? One feature is the ease of signing up at web sites. Just click. No more hassles with email address, links to click, waiting for that message to come through the spam filter, grey-lists. Immediate login. That could be a good feature for web shops. No more hassle with making accounts. A single click for customers to create an account, and you have a secure channel for a credit card transaction. As shop, offer a public RSS-feed with promotions instead of an email list. Make an encrypted RSS-feed and you have a personalised channel. Now make it tempting for customers to sign up and you get to see what each customer is interested in. If you send to much, your customers can unsubscribe by deleting the feed in their browser, knowing that you cannot reach them anymore. When they come back, you know it to if they use the same account. Otherwise, learn to be less agressive. Treat your customers as kings, and they appreciate it. Another (not a killer)-feature (for users) is that they are in control of the account. When they delete the private key, their account is closed. No one else can come later and claim the account. Unless they copied the private key beforehand. A benefit for site operators is that there is no personal data lying around in case of a breach of the server. Some european politicians already propose heavy fines (500.000 euros) for leaking personal details. Even if your customer was so stupid to re-use their gmail password for your little shop, you get the blame for leaking it. A smaller benefit, all traffic between you and your customer is encrypted so there can be no spying by people that want to plaster their advertisement onto your shop. What Phorm in the UK tried to do. This is all possible just by having a local CA that signs client certificates and a user agent that uses that. I hope you this list offers anything to kill for? Regards, Guido. signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Allergy for client certificates
On 10/11/13 14:52, Thierry Moreau wrote: Guido Witmond wrote (in reference to eccentric authentication): Another (not a killer)-feature (for users) is that they are in control of the account. When they delete the private key, their account is closed. No one else can come later and claim the account. Unless they copied the private key beforehand. Some reality check may turn this from a feature into a serious flaw: it's account continuity that matters to server-vendors and client-customers as well. Server: a very good customer account vanishes suddenly and pops up as a new account (which one?) among the 200 or so that made a first transaction during the next week. Even the vanishing event can not be detected! Client: I relied on the server to keep track of past purchase details, and for a crypto-?%# reason (do I care?) I lost them. Even worse, I can't create a new account with my real name (it says it's already enrolled while in fact it no longer works). Solving this issue in your experiment is going to re-introduce much of the PKI complexity. Sorry for asking tough questions, but maybe they would pop up sooner or later if this experiment goes forward. No problem asking. These things will happen. People will lose keys. Especially when they use lousy client computers and dev-null-backup strategies. The account discontinuity is part of the requirements trade off: In return for the ease of client account setup, the privacy, and client side control you get the responsibility of not losing your private key. However, as you're a good customer, call the shop, identify yourself until they are satisfied that you are their good customer and they will happily transfer your history to your new account, to keep your business. You are not entirely at risk for hostile takeovers. When you get an account request, create a new message for the personal (encrypted) RSS-feed. If you see it getting requested and downloaded, you know that - someone - still has access to the private key. Regards, Guido. signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Allergy for client certificates
On 10/09/13 15:50, Michael Rogers wrote: On 09/10/13 10:56, Guido Witmond wrote: You might want to take a look at my experiments. It's a user agent that does all the key management for you. It even does it with never asking anything more difficult than what username you want to have at a site. Hi Guido, It looks like you've worked around the UX issues by inserting an EC-aware proxy between the client and server. Who would be responsible for deploying such proxies? That proxy lives in the end user's computers. Right now, the user needs to install the proxy. I hope to get time and funding to make it a Firefox plug in. I hope that when it proofs useful browsers will adopt it. What happens if a user creates an EC account from a client machine with an EC-aware proxy and then wants to use the account from a client machine without a proxy? You need a user agent that is aware of EC. The alternative is to do all the rsa-calculations with grey cells. :-( This touches on another question I've been meaning to ask you: what happens if a user creates an account from a client machine, thus installing a client cert on that machine, and then wants to use the account from another machine? Just share the certificate with Firefox Sync like you share password accounts and bookmarks. Also, what happens if a user installs a client cert on a machine and then walks away, leaving their client cert exposed to the next user? With passwords there's an expectation that once you've logged out, the next user can't log into your account. But client certs break that expectation. First, don't do that. Using public access computers (at a library) is a bad idea anyway. Even if you can trust the library administrators, you don't know was at that computer before you. Second, I expect that every user has their own device. And that device has enough protections against abuse by others. For example, a screen lock that monitors if it is you who's using the phone and requests a fingerprint scan and a pin code or swipe style to unlock. (Cypherpunk Snowcrash style). Third. You have many certificates. Some have more value than others. You (the end user) has the option to encrypt certain private keys with a passphrase and a short unlock-interval. While not bothering with that for other keys. Each certificate is a separate identity. You don't share certificates over multiple web sites. Would you leave your phone in a hurry then someone can use those keys at their respective web sites to impersonate you. Until the screen saver kicks in. If your phone doesn't allow unprotected access to the filesystem where the keys are stored, they can't copy any of the keys. These are important usability questions that will need to be addressed sooner or later in future. However, they are all client side decisions. The server is not involved at all. So when the need comes, it can be implemented quickly. And different people can have different solutions. However, I want to keep it simple for now. I want to show how easy it can be to use certificates, to break that horrible browser UX. Regards, Guido. signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Allergy for client certificates
On 10/09/13 16:47, stef wrote: On Wed, Oct 09, 2013 at 02:50:59PM +0100, Michael Rogers wrote: This touches on another question I've been meaning to ask you: what happens if a user creates an account from a client machine, thus installing a client cert on that machine, and then wants to use the account from another machine? i guess the user has to use the crappy ui of the browser to extract it. while the browser vendors are polishing rounded transparent tabs instead. Talking about leaving your users in the dark Also, what happens if a user installs a client cert on a machine and then walks away, leaving their client cert exposed to the next user? With passwords there's an expectation that once you've logged out, the next user can't log into your account. But client certs break that expectation. indeed, client auth is bound to the browser in this sense and needs to be understood by the users, this is a cognitive entry barrier to usage. There is nothing that prevents a proper browser to share client certificates with their private key in Firefox Sync among a users' devices. In fact that would be good as a backup strategy too. Losing a private key means losing the account. Regards, Guido. signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Allergy for client certificates
On 10/09/13 00:18, Thierry Moreau wrote: Guido Witmond wrote: On 09/30/13 19:31, Thierry Moreau wrote: Perspective: I'm still working towards a working prototype based on (A) the client PPKP usage paradigm (Public-Private Key Pair) (B) the first party certification paradigm (get rid of requesting any client PKI certificate from any CA) (C) an end-user enrollment scheme that facilitates (B) (and PPKP usage migration in some respect) I guess, you and I have the same idea!. What do you think of my proposed solution: [0] Regards, Guido. 0: http://eccentric-authentication.org/blog I did look at it when you first made an announcement on this list. I looked at it very briefly again today. I am not sure you totally get rid of CAs. You seem to propose a CA for pseudonyms, freely available to arrange anonymous secure connections. Hi Thierry, I don't use Global CA's at all. Perhaps I need to clarify that point on my site: Each Local CA, one for each site, signs the server certificate for that site. It also creates a subCA that signs the customers' client certificates. Then store the root CA private key offline. When a visitors sign up, they get a client certificate signed by the subCA. Whenever a customer visits the site again, their user agent (browser) checks the server certificate to learn the CA and the agent only offers the client certificates that match that server certificate CA. This protects the user against phishing as the crooks can redirect DNS and DNSSEC (by hacking into the DNS-registrars) but they cannot copy the site's root Certificate. That should live offline on a smart card/hsm. The user agent cannot offer this protection with Global CA supplied server certificates. There is nothing for the user agent to tie the client accounts to: Not the server certificate, because that changes every year because the CA wants (more) money. Not the CA-root because that one is used to sign many site certificates, giving the same problem again of selecting the correct client certificate amongst the many in my browser. And if the agent ties the client certificate to the domain name of the site, it falls prey to phishers who can use a Diginotar attack. And apparently NSA can do that in real time. Perhaps I should give the local CA a different name. Regards, Guido. signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Allergy for client certificates
On 10/09/13 00:41, Tony Arcieri wrote: On 09/30/13 17:43, Adam Back wrote: Anyway and all that because we are seemingly alergic to using client side keys which kill the password problem dead. As for web browsers, client certs have a ton of problems: 1) UX is *TERRIBLE*. Even if you you tell your browser to use a client cert for a given service, and you go back to that service again, browsers often don't remember and prompt you EVERY TIME to pick which cert to use from a giant list. If you have already authenticated against a service with a given client cert, and that service's public key hasn't changed, there's absolutely no reason to prompt the user every single time to pick the cert from all of the client certs they have installed. 2) HTML keygen tag workflow is crap and confusing. It involves instructing users to install the generated cert in their browser, which is weird and unfamiliar to begin with. Then what? There's no way to automatically direct users elsewhere, you have to leave a big list of instructions saying Please install the cert, then after the cert is installed (how will the user know?) click this link to continue 3) Key management UX is crap: where are my keys? That varies from browser to browser. Some implement their own certificate stores. Others use the system certificate store. How do I get to my keys? For client certs to replace passwords, browsers need common UI elements that make managing, exporting, and importing keys an easy process. Passwords may be terrible, but they're familiar and people can actually use them to successfully log in. This is not the case for client certs. They're presently way too confusing for the average user to understand. Hi Tony, You might want to take a look at my experiments. It's a user agent that does all the key management for you. It even does it with never asking anything more difficult than what username you want to have at a site. See the parts on 'signing up' and 'manage accounts'. I hope it sparks your interest. Regards, Guido. 0: http://eccentric-authentication.org/blog/2013/06/12/walkthrough-datingsite.html signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Allergy for client certificates
On 09/30/13 17:43, Adam Back wrote: Anyway and all that because we are seemingly alergic to using client side keys which kill the password problem dead. Hi Adam, I wondered about that 'allergy' myself. I have some ideas about that and I'm curious to learn about other. Here are mine: 1. The long standing belief is that client systems are untrustworthy. Any malware will go after the client certificates. So without proper sandboxing, capability-security and other partitioning mechanisms, the user is toast. The most popular consumer-OS was (is?) also the most leaky. Where was The Hurd when we needed it? Why did people fall for Unix when Multics was so much better? 2. It's easier to change a password in a database than to talk the user through creating an submitting a new pub/priv key pair. 3. The crypto-programs were too diffucult to use. Requiring end users to make trust decisions about entities they never heard of. Who is Verisign and why should I trust them 4. Client certificates from the big CA-peddlers are akin digital passports, eliminating all non-repudiation. Ie, a privacy problem. 5. Only recently, computers have become powerful enough to encrypt everything, all the time. Now we can afford to burn cpu cycles on encryption without getting usability to suffer. Guido. signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Eccentric Authentication again
Hello all, I've written two new blog entries on eccentric authentication. The protocol that uses client certificates and a local CA to distribute public keys between strangers in a secure way. Please read in this order: http://eccentric-authentication.org/blog/2013/08/31/the-holy-grail-of-cryptography.html http://eccentric-authentication.org/blog/2013/09/05/a-subversive-idea.html I'd love to hear comments, remarks, improvements. Regards, Guido. signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] skype backdoor confirmation
On 15-07-13 14:59, Jeremy Stanley wrote: On 2013-07-15 09:34:46 +0300 (+0300), ianG wrote: Indeed, it seems that Skype lost their privacy mojo somewhere between eBay and Microsoft. [...] I still don't understand where it ever got privacy mojo to start with, even before eBay. Skype was written by the authors of KaZaA. Exactly! From the people that gave the music industry the finger. Can't be bad guys, then. Guido. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] post-PRISM boom in secure communications (WAS skype backdoor confirmation)
if ever we managed to provide an interface where users successfully managed their own keys without screwing up. The only answer is to take key management out of the users' hands. And do it automatically as part of the work flow. Guido. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] post-PRISM boom in secure communications (WAS skype backdoor confirmation)
On 30-06-13 09:44, James A. Donald wrote: On 2013-06-30 5:13 PM, Danilo Gligoroski wrote: This was expected. As Skype definitely ruined its reputation as free end-to-end application for secure communication, other products are taking their chances. Agencies showing sudden interest in encrypted comm --- http://gcn.com/blogs/cybereye/2013/06/agencies-sudden-interest-encrypted-com m.aspx [...] expects end users to manage their own keys, which is of course the only way for end users to be genuinely secure. Agree However, everyone has found it hard to enable end users to manage keys. User interface varies from hostile, to unbearably hostile. Disagree. Not everyone. I believe this below to be a way out of the unencrypted web into an crypto-by-default web that is easy for the end user. It should be so easy that the users do not realize that they are using cryptography. It should be part of the account creation and log in process. Imagine: - forget passwords and password accounts; we use client certificates; - place a certificate signer at each website signing only for that site; - every CSR is signed without ado as long as the CN is unique at that site; - the CN is really the account name; - end user decides the CN; - the user uses a local agent to manage - the user agent logs in with the certificate at the site; To protect the user against an external party performing a MitM we publish the servers' TLS certificate in DNSSEC with DANE. This makes the sites CA unique and the certificate world wide recognizable identities. (Anonymous identities as there is no need to hand any personal identifying information at certificate signup). With the public and private key pair, the users can encrypt and sign messages between each other with message delivery either via the site or via any third party message delivery. To protect the user against a sites' signer creating a shadow certificates of its own users we deploy a global registry of client certificates. The registry monitors if a site ever signs two certificates for the same CN. If so, the site loses all respect. Users' agents are expected to check that registry before signup at a site, and when starting to communicate with another user at the site. Once a few messages have been send and received by any two end users, they have sufficient trust there is no MitM. There can be even more advanced benefits with a small change in web browsers: - phishing protection; - XSS, CSRF protection, making javascript web applications secure. It's here: http://eccentric-authentication.org/ Cheers, Guido. PS. It needs Tor to protect against traffic analysis, it needs Capability operating systems for the end user to protect the users' keys. PPS. I'd love to see some funding to keep me going with this. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] why did OTR succeed in IM?
On 03/23/2013 10:25 AM, ianG wrote: Someone on another list asked an interesting question: Why did OTR succeed in IM systems, where OpenPGP and x.509 did not? I find that interesting too. What list would that be? Guido. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Client TLS Certificates - why not?
On 03/04/2013 08:22 AM, str...@riseup.net wrote: Hi, Can anyone enlighten me why client TLS certificates are used so rarely? It used to be a hassle in the past, but now at least the major browsers offer quite decent client cert support, and seeing how most people struggle with passwords, I don't see why client certs could not be beneficial even to ordinary users. Hi Strife, I'ld like to add a few cents too: The whole x509 client and server certificates were designed to be used with a global directory, called x500. The idea is that you can lookup the key of person you want to communicate to. Although this 'secures' the communication against tampering and keeps the contents confidential, it lacks three properties: - there is no way to securely communicate with total strangers; you need to know their name - privacy: every person has one-true-certificate-to-bind-them; - repudiation: there is no way deny writing a message; leading to self censoring. In other words, everything I sign with my Thawte client certificate is tied to my identity *for life*. That's why I don't use that thing. In fact, I've long since lost the private key for it. With password based accounts, I can decide to write under any pseudonym and keep control of my privacy, at the price of having the hassle with passwords. I've tried to write a blog[1] on it. Another reason why the Crypto-heaven did not materialise is that the current crop of operating systems is completely unfit to protect the user's interests. As soon as one piece of malware is inside, it's not your computer anymore. And with that the malware can abuse your expensive client certificate at will. I believe only micro-kernel operating systems with POLA security layers on top of that can bring solace. See Qubes-OS, Genode, Minix. Without such security any progress to use cryptography is doomed. See 'Dancing Pwnies' on wikipedia. IanG and Peter Gutmann are completely correct that usability is key. Browsers have a long way to go. For example, log in at CAcert with your client certificate. That's easy. Now try to log out. That's impossible. The only thing you can do is to close your browser. Losing all other open tabs with it. I've come up with a way to get out of this mess. I call it Eccentric Authentication.[2] It's a protocol that will provide pseudonymous client certificates, eliminates passwords, allows total strangers to communicate securely at a dating site. With the addition of a *Cryptographic Same Origin Policy* we can end CRSF, block the most obnoxious advertisment-spies while still allowing CDN-networks, javascript-applications. I've designed a fully anonymous dating site where you _can_ limit abuse. I've written about that too. In fact, my whole website handles about it. Feel free to explore and ask if things are not clear. Cheers, Guido Witmond. 1: http://witmond.nl/blog/2012/11/21/why-we-still-use-passwords.html 2: http://witmond.nl/ecca/ecca.html ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Client TLS Certificates - why not?
On 03/04/2013 06:10 PM, StealthMonger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Gutmann pgut...@cs.auckland.ac.nz writes: ... sit behind her with your arms crossed so you can't point to anything or type stuff out for her, and walk her through the process of acquiring and using one without leaving your chair or performing any part of the operation for her. Now imagine getting her to do the same using only a sheet of instructions you've written. Mother sits down at her computer to do email. Computer notices that she does not have an encryption key (client-side certificate), starts a background process to generate one, and tells her: From now on, you will have a new email address. Starting next week, the old one will no longer work. This will be the only computer on which you can receive email. If you ever want to use another computer, press Add/Change Computer below. [Computer finishes generating key with key ID xlzoazsabewlcc.] Your new email address is xlzoazsabewlcc. It is now being broadcast worldwide. Tell your bank and all your friends. How do you get that address communicated over the phone? Let me try and help your mother: Mother sits at computer, and asks: What now? Me: 1. open firefox, install the secure email addon from: mozilla/addons/guidos-secure-email-plugin.xpi She installs it. 2. browse to https://guidos-secure-mail.com/ She: how do you spell that? Me: h-t-t-. dot com (with hands at my back) 3. Web browser connects to server, and the plug in validates server certificate against DNSSEC/DANE specified Root certificate. (It won't connect if there is an error here) 4. I ask her to press the 'Signup' button at the plugin (on the browser chrome, not in the window) Browser plugin asks for username: Mom types: StealthMongersMom and she presses the ok-button. 5. Browser plugin requests client certificate at guidos-secure-mail.com with her chosen username. Browser receives certificate from the site, signed with a subCa of the same RootCa certificate as the server. Username must be unique, otherwise she needs to choose something different. Mom has all she needs to send and receive secure mail. 6. Mom phones offspring and says I've got an email address: it's stmomo@@guisecmail.com (unintelligible due to line noise) 7. You: How do you spell that? 8. She: S-t-e-a. . . m-a-i-l dot com 9. You type it in and your browser plugin looks up https://guidos-secure-mail.com/cert-of?id=StealthMongersMom It validates the server certificate and checks if the client cert is chained to the same RootCA. 10. You write your message, sign it with your private key, encrypt it with your public key and deliver the ciphertext to https://guidos-secure-mail.com/deliver?to=StealthMongersMomciphertext=MIIABC...XZY=== (openssl s/mime encoded message, without headers) 11. She logs in with her certificate, the site delivers the ciphertext and the plugin decrypts it with her private key 12. The plug in retrieves the certificate for the sender-address (StealthMonger@@nym), validates it against the DNSSEC/DANE RootCA for nym... and has a validated return address. 13. Your mom presses the reply-button, composes a message, her plug signs it with her private key, encrypts it with your public key. She delivers the message at nym...//deliver?to=StealthMongerciphertext=MIIDEF...ABC=== (important not to send to guidos-secure-email.com) 14. You receive the message and when the message signature matches that of the client certificate you got from step 9 you know that there is no man in the middle at guidos-secure-mail.com impersonating your mom. My site does not have your mom's private key to do so. Notice that mom didn't validate any keys, nor did she ask you for your address. She just assumes that the first mail she gets is from you. It's the contents of the message that does the validation for her. Just like ordinary email. Anyone else who can log into this computer has access to all your bank accounts and email. Please use Qubes-OS, Genode, Minix or any other POLA based OS and user interface to prevent the Dancing Pwnies. With Swiss-cheese-OS we can never reach security nirvana... Make sure your login password is strong. Please don't use passwords, use a GPG key on a crypto-stick.com. Upcoming version 2 of the stick can store plenty of certificates and private keys on its secured sd-card. Cheers, Guido. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Client TLS Certificates - why not?
On 03/04/2013 11:15 PM, Open eSignForms wrote: Step 10 will make it impossible for you mom. ;-) 10. You write your message, sign it with your private key, encrypt it with your public key and deliver the ciphertext to https://guidos-secure-mail.com/deliver?to=StealthMongersMomciphertext=MIIABC...XZY=== https://guidos-secure-mail.com/deliver?to=StealthMongersMomciphertext=MIIABC...XZY=== (openssl s/mime encoded message, without headers) You're right. Wrong key for encryption. Should use mom's public key for encryption. Thanks, Guido. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DNSSEC/DANE in CT. Was: Why anon-DH is less damaging than current browser PKI
On 01/07/2013 08:08 PM, Ben Laurie wrote: On Mon, Jan 7, 2013 at 5:32 PM, Guido Witmondgu...@wtmnd.nl wrote: What I read from the certificate-transparency.org website is that it intends to limit to Global CA certificates. I would urge mr Laurie and Google to include all certificates, including self-signed. It would increase the value of CT for me, especially in combination with DNSSEC/DANE The problem with self-signed for CT is twofold: 1. spam. 2. revocation. Given a solution to these I would happily include them in CT. CT + DNSSEC/DANE + self-signed is a different matter, but one that should probably address DNSSEC directly - that is, transparency for DNSSEC keys, not for TLS certs mentioned in DANE records. I don't know enough how self signed server certificates would add to the spam or revocation problem. Please let me first phrase what I think I understand of CT and why I want to include self signed certificates. If I understand correctly: 1. CT is a way to keep/make global CAs honest by listing all certificates signed by them, indexed by domain name. 2. CT allows to lookup hashes without leaking to third parties what sites I browse to. Both goals are direly needed. Thank you for pursuing it. A global server certificate is nothing more than a binding from domain name to a public key. It is designed to prevent a DNS-attack against my resolver that lures me to an attacker. Secondly, it provides a key to secure the communication against sniffing and tampering. With DNSSEC and DANE, I don't have that problem as my resolver can validate both the correct ip-address and the server-certificate. Even if it is a self-signed certificate. I don't need the global CAs anymore for that. Now I don't want to _trust_ DNSSEC completely either. A registrar might get pressured to change the ip-address and certificate for a site. In fact, DNSSEC and DANE would make that attack easier as there is only one party to pressure. For that you would need to log the self signed certificates, not (just) the dnssec-keys. CT would allow me to view the history of a certificate for the domain name. Even if it was a self signed certificate. It would let my browser to make a more informed decision whether to trust a site as Peter Gutmann promotes. Perhaps you might want to leave the unpublished self signed certificates out of the log, to pressure people to use either global CAs or DANE. With regard, Guido Witmond. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Client certificate crypto with a twist
Hello Everyone, I've done my homework and come up with a new description of Eccentric Authentication and what it, I humbly believe, can bring us. I hope it's more clear than my previous ramblings. It's a big piece at https://www.ecca.wtmnd.nl/explanation.html. TL;DR: Client certificates have a lot of unused potential. My protocol allows to create client certficates easily and cheaply. That solves the Yet-Another-Account problem. It allows unknown parties to communicate securely and anonymously. I give the example of a dating site that allows members to communicate private messages without the site being able to read any of it and still preserving the complete anonymity of the site members. I go further and with the use of DNSSEC and DANE, I can communicate a client certificate over the phone to bootstrap a secure channel. The hard part is, as some responses in this thread already mentioned, browsers are really not up to it. We need to change the web browser into a User Agent that puts the users interests first. With kind regards, Guido Witmond. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Client certificate crypto with a twist
Hello Everyone, I'm proposing to revitalise an old idea. With a twist. The TL;DR: 1. Ditch password based authentication over the net; 2. Use SSL client certificates instead; Here comes the twist: 3. Don't use the few hundred global certificate authorities to sign the client certificates. These CA's require extensive identity validations before signing a certificate. These certificates are only useful when the real identity is needed. Currently, passwords provide better privacy but lousy security; 4. Instead: install a CA-signer at every website that signs certificates that are only valid for that site. Validation requirement before signing: CN must be unique. The long version: Clients can choose the CN they wish to have, that is, they can chooose their own username under which they wish to be known to your site. The CA of the web site signs the request (at sign-up time) when the CN is unique for the site. That's the only requirement. The certificate is axiomatically accepted by the site that created it, the certificate is categorically rejected at every other site. Each site only trust their own CA. The certificate binds the username and the users' public key to the CA. It thus creates a cryptographic pseudonym. The user can use this pseudonym to establish a reputation at for example, a blog site, movie critics or shopping recommendations. This simple uniqueness property without the X500 global identities gives people the power of cryptograhy with the privacy equivalent of password authenticated accounts. In addition, with the right browser plugins, it allows people to write private messages to each others, properly encrypted and authenticated with the key and certificates without having to rely on the site to keep it private. The crux, I state it is easier to secure the CA that signs requests than it is to secure a password database that is needed at every log in. If a break-in would happen at either the site, or the CA, there would be nothing to steal nor could it lead to a compromise of a third party account of the user. No worries about getting sued by users that reuse passwords among several sites. The only thing of value is to duplicate the users' id at the site. And that would be detected by the different serial number on the certificate. To improve robustness even more, the CA installs a two-level CA-structure: The root key signs a sub-key. The root key is kept offline. The sub-key is used to sign the clients' CSRs. Your sites accepts every certificate from every certificate chain that leads back to your root certificate. Every once in a while, you delete the private key of the sub-key and replace it with a new one. Sign the new key with your root-key. This procedure sets the clients certificates signed with the old keys 'in stone'. If you ever need to revoke a certain certificate from accessing your website (due to misbehaviour or spamming), just blacklist the certificate until its expire date. No need for OCSP or other revocation protocols. Cheers, Guido Witmond. PS. The devil is in the details. Most web browsers cannot handle client certificates easily. That would require some work. PPS. To read more: https://github.com/gwitmond/eccentric-authentication To see a silly example implementation: https://www.ecca.wtmnd.nl/ It only works - more or less - with a Firefox browser. PPPS. Probably I'm reinventing some existing ideas. I'ld love to hear about those. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
