Re: MITM in the wild
On 081018 at 20:30, Nelson B Bolyard wrote: FF3 had utterly failed to convey to her any understanding that she was under attack. The mere fact that the browser provided a way to override the error was enough to convince her that the errors were not serious. I find it amazing that someone shows this level of ignorance but then manages to file a bugreport... :-) KCM would not have helped. If anything, it would have reduced the pain of overriding those errors to the point where the victim would never have cried for help, and never would have learned of the attack to which she was a victim. The question is: how can FF3+ *effectively* protect users like her from MITM attackers better than FF3 has already done? Personally, I like the idea of a 'safe mode' in the browser. Safe-mode is very visible, provides limited scripting and https-only to a defined set of sites. If mom wants to go banking, she's been told she has to activate safe-mode. Otherwise banking is insecure. It is some action that the user initiates, she tells the program when some critical operation starts and ends. If she has to exit safe-mode to go to a bank then that is a very obvious decision to test her luck. Is removal of the ability to override bad certs the ONLY effective protection for such users? No. Vista/IE7 seems to ship with various scripting deactivated by default. So what happens? The page worked before, now it doesn't. Thats clearly a problem of the stupid new computer. So we ask the neighbour's kid to solve this and everything 'works'... I do though would like some sane alternative for people who are aware of the certificate stuff. The possibility to chose Yes/No/Ignore with one click and to optionally display certiciate details plus KCM info instead of a verbose warning. /steffen ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comment on tls-srp enhancement?
On 071216 at 01:50, Nelson Bolyard wrote: Steffen Schulz wrote, On 2007-12-12 10:34: On 071209 at 03:55, Nelson Bolyard wrote: If FF doesn't have any built-in UI for SRP, I think I have a harder time justifying the inclusion of SRP in NSS. I think it's a feature that would be included exclusively for use in the browser, so if the browser can't use it out of the box, there may be push back on it. SRP is a great protocol also for authentication against your email provider or WLAN[1] access point. It adds KCM through the user password, an entity that needs to be managed anyway. That last sentence seems to depend on the assumption that passwords (and more generally, shared secrets) are unavoidable, necessary, and desirable. I don't share that view. No, me neither. The assumption is that pw-based logins will continue to stay around quite for some time. Distribution of (useful) certificates or tokens seems to be very difficult in many environments. The (probably many) reasons for this don't seem to be all that clear and difficult to address. Maybe the breakthrough will come tommorrow morning, maybe next week. I think we should invest a little effort to tighten what we have to use every day. But even with SRP, shared secret systems continue to have many major drawbacks (e.g. users tend to re-use the same password for many servers, or tend to write them down and/or store them insecurely.) Jep. It's not only protecting your password but also strengthens authentication in the face of the common PKI dilemma. The common PKI dilemma? I'm not very keen on discussing that stuff...what I think of as 'the' pki dilemma are the consequences of the tradeoff that is done by delegating trust relations. The introduced trust delegation concept makes the problem of distributing identity information manageable. But its still a hard problem except for closed environments *and* most people really don't understand why and when to trust Verisign to athenticate Amazon. I'd have a hard time myself to explain to my mum why one should trust verisign more than the person at the airport that I ask to look after my luggage. 'Because it would ruin their business' is pretty incomplete. That issue is actually not all of what I meant above, although the other stuff could be regarded as consequences: - people don't understand trust delegation to unknown parties(Verisign?) - most phishing sites don't even use SSL. People haven't even startet to attack SSL(maybe because it's secure) - most of the time, protocol failures are not due to attacks: its easy to do things wrong + we're still stuck with the distribution problem - It fails badly(of course I want to continue, why'd you think I clicked that link?! How would I know if it's secure before starting the transmission?) That said, I agree that web-authentication is the major use case for TLS-SRP in NSS. Let me make my original point in another way. It was a suggestion that you should either (a) contribute code to the browser so that it will have the UI necessary to make use of TLS-SRP, or (b) work with the browser developers to get them to agree to develop that code. I found previous attempts in bugzilla to do something in this area. I'll see if I can reach someone over there.. [1] Actually a huge problem, think of PEAP, LEAP, EAP-TLS, EAP-TTLS, the Cisco-crap etc. All failed attemps to provide secure pw-auth in a not-so-secure PKI environment. I would have said: All attempts to keep shared secret authentication alive in the presence of protocols that don't need it. And hopefully, with usb-tokens and smartcard readers getting cheaper, the day will come where such solutions have sufficient software support to be usable. I don't think we're there yet, it's a lot of work to deploy tokens at home and it's easy to make mistakes. I've seen the needed functionality in software suites from security vendors, expensive products that are targeted at other companies, not end users. regards, /steffen -- Bildet Olsenbanden! ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comment on tls-srp enhancement?
Hi, On 071213 at 16:30, Michael Ströder wrote: Steffen Schulz wrote: SRP is a great protocol also for authentication against your email provider or WLAN[1] access point. [..] That said, I agree that web-authentication is the major use case for TLS-SRP in NSS. Hmm, without having looked at tls-srp but from my experience SSL/TLS connections are quite often terminated at a reverse proxy. But the password-based authentication information is passed to an application server beyond that reverse proxy which checks the password by some means. I guess in case of tls-srp the reverse proxy (as TLS end point) would have also to check the password. This is not what most of my customers deploying reverse proxies want. What is definitely needed for larger environments is the ability to do user authentication at the backend, not at the web server or whatever your SSL endpoint may be. SRP does not need its transmissions to be secured in any way, so there is no problem in relaying the data to somewhere else. And, it may be bad design or an otherwise flawed idea, but TLS-SRP in NSS includes a PKCS11 interface that does exactly this: Relaying all protocol data to a an entity that holds long-term secrets and does all authentication, returning only the common session key to SSL. (Lucky me, there is some use to the pkcs11-stuff after all.. ;-) ) /steffen -- Holzhacken ist deshalb so beliebt, weil man bei dieser Tätigkeit den Erfolg sofort sieht. -- Albert Einstein ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comment on tls-srp enhancement?
On 071209 at 03:55, Nelson Bolyard wrote: If FF doesn't have any built-in UI for SRP, I think I have a harder time justifying the inclusion of SRP in NSS. I think it's a feature that would be included exclusively for use in the browser, so if the browser can't use it out of the box, there may be push back on it. SRP is a great protocol also for authentication against your email provider or WLAN[1] access point. It adds KCM through the user password, an entity that needs to be managed anyway. It's not only protecting your password but also strengthens authentication in the face of the common PKI dilemma. That said, I agree that web-authentication is the major use case for TLS-SRP in NSS. So the plan was to create a FF extension instead. One that 'fixes' how the security status is displayed(and perceived, hopefully), and also includes some other ideas with regards to phishing attacks. Then the patch against PSM should be very small if needed at all. I hope this way it will be easier to settle on the way the security interface should work and it may also help to evaluate how some other ideas perform. Easier? Because it's easier to obtain forgiveness than permission? :-) Because the usability of such an interface is easier to evaluate and debug when it does not exist as a outdated crude patch to mozilla cvs head. It's an primarily an academic project. Anyway. I'll try to find my way through the code that handles NSS. It'll probably go a lot faster for someone who knows psm or c++, but I guess there all busy, too.. regards, /steffen [1] Actually a huge problem, think of PEAP, LEAP, EAP-TLS, EAP-TTLS, the Cisco-crap etc. All failed attemps to provide secure pw-auth in a not-so-secure PKI environment. -- Getting there isn't half the fun, it's all the fun. -- Robert Townsend ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Comment on tls-srp enhancement?
Hi all, I was hoping for some feedback on bug 405155, which adds support for TLS-SRP. Are the core devs that busy right now? (I also thought subscribing to this list would enable me to follow the current development around nss/psm. Do you just use bugzilla?) regards, steffen -- Bildet Olsenbanden! ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Testing DSA ciphersuites..
On 070825 at 02:10, Nelson B wrote: IIRC, the problem is not DSA but rather DHE. NSS does not presently support any DHE cipher suites on the server side, and it so happens that all the DSA cipher suites are also DHE cipher suites. IIRC, the missing code is not for DSA but for DHE. The issue is the sharing You are right, I was able to sign my ServerKeyExchange with DSA. I thought SSL didn't know about the supplied certificate but it was indexed as kt_null. Is there a reason for not activating TLS ciphersuites by default? I need to explicitly enable my TLS ciphersuites when using the 'server' sample application. /steffen -- Hi, I'm a unix-virus. Please copy me into your .signature to help me spread! ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Testing DSA ciphersuites..
On 070824 at 03:20, Wan-Teh Chang wrote: Is usage of DSA-suites disencouraged? How can I test them? No, the use of DSA ciphersuites is not discouraged. But we haven't implemented DSA ciphersuites on the server side. They are only implemented on the client side. I believe this is the problem you're running into. Okay. How much is missing to use DSA-suites in the 'server' sample program? The calls to look up the certificate and supply it to ssl look rather generic. OTOH, the server signing routines in the ssl library seem to be missing.. /steffen -- No matter where you are... Everyone is always connected. - Serial Experiments Lain ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Testing DSA ciphersuites..
On 070824 at 16:47, Wan-Teh Chang wrote: On 8/24/07, Steffen Schulz [EMAIL PROTECTED] wrote: Yes, most of the missing code is in the SSL library. There is a work-in-progress patch in the bug report for this feature: https://bugzilla.mozilla.org/show_bug.cgi?id=102794 I see. No, I'm currently working to implement TLS-SRP as a university project. The ciphersuite can optionally include RSA or DSA authentication. http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-14.txt I plan to file a bug report and a patch in a few weeks. I didn't know about the pkcs11-layer, this will follow.. /steffen -- # (o_ #+49/1781384223 //\-xgpg --recv-key A04D7875 V_/_Use the source, Tux! mailto: [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Testing DSA ciphersuites..
On 070824 at 03:20, Wan-Teh Chang wrote: Is usage of DSA-suites disencouraged? How can I test them? No, the use of DSA ciphersuites is not discouraged. But we haven't implemented DSA ciphersuites on the server side. They are only implemented on the client side. I believe this is the problem you're running into. Okay. How much is missing to use DSA-suites in the 'server' sample program? The calls to look up the certificate and supply it to ssl look rather generic. /steffen -- No matter where you are... Everyone is always connected. - Serial Experiments Lain ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Testing DSA ciphersuites..
Hi, I want to test DSA ciphersuites, but 'server' and 'selfsrv' seem to be unable to handle them. I changed the source to enable some TLS-DSA suites but it seems the ssl library is not being supplied with a valid certificate. I created the dsa certificates with: openssl pkcs12 -export -in dsa.crt -inkey dsa.key -out dsa.p12 -name dsa_srv pk12util pk12util -i dsa.p12 -d certs Is usage of DSA-suites disencouraged? How can I test them? /steffen -- Bildet Olsenbanden! ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
TLS SRP extension
Hi all, I'm currently implementing draft-ietf-tls-srp-13 in NSS/SSL. I did not find suitable test programs. I mean something like openssl or gnutls-cli. It seems I would have to dig through the test shell scripts and programming examples to find or program such a tool and make it find the nss libs it needs. My primary goal was to get a working implementation of Firefox+SRP. That's why I have been working with the latest mozilla/firefox from CVS until now. All proposed ciphersuites are currently working with OpenSSL+SRP as server and hardcoded login/passwd. Now I have to implement a new callback function that provides the user login to NSS/SSL. And I think it might be better to be able to test it inside the NSS distribution only(input validation, better control over SSL states). So, is there a tool like openssl/gnutls-cli somewhere? Or a simple CLI client outside the NSS distribution? I also have a question concerning the implementation. As far as I can see, the PKCS11 interface is only useful if there is cryptographic hardware installed? I can not see an advantage to the SRP protocol, as it does not need certificates or secret keys. My problem is that the PK11-stuff looks rather complex. I was not able to compute the pre-master secret using PK11, so currently only the bypass-path is working. And even with opt.bypass set, the cipher-suite lookup fails due to missing PK11 support. I suppose, this is a problem? How are these PK11 slots supposed to work? I've also left out the server support, as it is not part of the university project. But I don't think it would be much work, now that I know how everything is supposed to work. If you would consider the project to be included into NSS, I will do what I can to improve the patch so it can be included. I can provide diffs to firefox cvs head, but the code still needs work and cleanup. My first larger project, any comments appreciated. Regards, Steffen SRP project: http://srp.stanford.edu/ TLS-SRP draft: http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-13.txt -- [EMAIL PROTECTED]gpg --recv-key A04D7875 Key fingerprint: B805 57BE E4AF 0104 CC51 77A1 CE6F 8D46 A04D 7875 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Applicability of SSL / use-cases
On 070204 at 16:00, Ben Bucksch wrote: In private discussion, Eddy of StartCom suggested SSL CA certs for * internal sites (company webmail/IMAP, VPN etc.) * private discussion (blogs, forums, chat) * generally everything where you supply a login/password. I think other solutions are more appropriate in each case. Generally, SSL has a root weakness: Certs expire and can be replaced with new ones silently. This means *any* root CA (e.g. VeriSign) can issue a cert and hand it to a TLA and my communication partners will not notice anything. This weakness exists until certs are everlasting (breaking the current revenue model of CAs) and clients (browsers etc.) store certificates that they have seen, similar to SSH. I.e. PKI would be used only for the *first* contact. That is why I think a browser should do this. One should in general be notified when the current certificate fingerprint does not match what has been seen before on this site, independent from who signed it. Maybe with a side note on the expire-date of the last-seen cert. Add some heuristics to help the end user judge the security level. Currently, there is near to nothing. I tried to implement this as a FF extension but it seems one can not access the SSL-properties of a connection via the extension-interface.. This problem means that SSL is only appropriate for normal business, where governments and CAs are not enemies, but is not suitable for private communication and highly sensitive data. I disagree. If you are in a large corp it may make sense to have your own CA, independent from some 'real' CAs. What tPKI gives you is scaleability, but you need to invest trust(which is bad). Private communication: Problem as described above. Initial contact can gain from PKI, but only where realname is important. Given that most people use nicknames, and it works just fine, not even that really matters. The only thing that is important is that the Fred I know is always the *same* Fred. Self-signed certs (SSH model) achieve that. SSL does *not* guarantee that. Whether Fred is actually Joe in real life makes no difference to me. Internal sites: I think these should use self-signed certs, and *reject* CA-signed ones. This is possible, because a physical, thus secure out-of-band, communication is possible. I think CAs are actually the weak link here, because they are an external party. They are not if the CA is run by your company. Especially if you can tell the browser to accept this CA for *.you-company.com only. But indeed, a lot of 'cheap' CAs came up and even if you trust e.g. cacert to carefully check what they sign and take good care of the secret key, there is always some risk left. In these cases, the browser will not notify you in any way, which makes this particulary dangerous. Login: Use HTTP Digest (although nobody uses it :-( ). That's vulnerable to MITM, though, right? Is there a way to avoid it? I don't see one. You can not avoid MITM without *some* common secret(or one known asymetric secret per peer). Once you have something, you can build up on that. E.g. put the common bits into the exponent of a DH exchange. This is something I find very promising. People are often doing client-authentication inside SSL, be it banking or some forum. This is a common secret that, once established, can really make a difference. As Mozilla/Firefox is not using OpenSSL or GNUtls, I'm currently trying to implement this in NSS as part of my studies. AFAIK, there are currently SOKE and SRP-TLS out there. SRP-TLS is more complicated, but a little more secure in that the server does not need the cleartext password. Maybe someone can comment on that? (great/useless/...) /Steffen ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
