Re: TLS-SRP & TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
> "Werner" == Werner Koch <[EMAIL PROTECTED]> writes: Werner> The last time I checked the Mozilla code they used their own crypto Werner> stuff. When did they switched to OpenSSL and how do they solve the Werner> GPL/OpenSSL license incompatibility? Indeed they do. It is called nss, is available as a package of its own on several dists, is written in C, is MPL|GPL|LGPL and has its own page at: http://www.mozilla.org/projects/security/pki/nss/ The Gentoo ebuild even installs a pkgconfig file. I don't recall seeing anything !zilla using it, though. -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: TLS-SRP & TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
On Sun, Feb 10, 2008 at 07:27:28PM +0100, Werner Koch wrote: > On Thu, 7 Feb 2008 16:37, [EMAIL PROTECTED] said: > > > I don't have any idea why or why not, but all they can release now is > > source code with #ifdef openssl >= 0.9.9 ... do PSK stuff ... #endif, > > The last time I checked the Mozilla code they used their own crypto > stuff. When did they switched to OpenSSL and how do they solve the > GPL/OpenSSL license incompatibility? > You are probably right about that, they use the "NSS" library. It is sometimes easy to forget that not all the world is OpenSSL... -- /"\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: TLS-SRP & TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
On Thu, 7 Feb 2008 16:37, [EMAIL PROTECTED] said: > I don't have any idea why or why not, but all they can release now is > source code with #ifdef openssl >= 0.9.9 ... do PSK stuff ... #endif, The last time I checked the Mozilla code they used their own crypto stuff. When did they switched to OpenSSL and how do they solve the GPL/OpenSSL license incompatibility? Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: TLS-SRP & TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
Peter Gutmann wrote: Victor Duchovni <[EMAIL PROTECTED]> writes: While Firefox should ideally be developing and testing PSK now, without stable libraries to use in servers and browsers, we can't yet expect anything to be released. Is that the FF devlopers' reason for holding back? Just wondering... why not release it with TLS-PSK/SRP anyway (particularly with 3.0 being in the beta stage, it'd be the perfect time to test new features), tested against existing implementations, then at least it's ready for when server support appears. At the moment we seem to be in a catch-22, servers don't support it because browsers don't, and browsers don't support it because servers don't. I would say that this would not hold the FF developers back, as they were definately capable of implementing TLS/SNI extension a year or two back, without any support from stable libraries in Apache httpd, Microsoft IIS, etc (still waiting...). I'd also suggest that the TLS/SNI (which will apparently turn up one day in Apache) will have a much more dramatic effect on phishing than TLS-PSK/SRP ... because of the economics of course. Lowering the barriers on all TLS use is far more important than making existing TLS use easier. Of course, this is not a competition, as the effect adds, not competes. The good thing is that we may actually get to see the effects of both fixes to TLS rollout at similar times. In economics, it is a truism that we can't run the experiment, we have to watch real life, Heisenberg style, and this may give us a chance to do that. Also, we can observe another significant factor in the mix: the rollout of virtual machine platforms (xen and the like) is dramatically changed the economics of IP#s, these now becoming more the limiting factor than they were, which might also put more pressure on Apache ... to release earlier and more often. iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: TLS-SRP & TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
Peter Gutmann wrote: There's always the problem of politics. You'd think that support for a free CA like CAcert would also provide fantastic marketing opportunities for free browser like Firefox, but this seems to be stalled pretty much idefinitely because since CAcert doesn't charge for certificates, including it in Firefox would upset the commercial CAs that do (there's actually a lot more to it than this, see the interminable flamewars on this topic on blogs and whatnot for more information). The situation with CAcert and Mozo is fairly simple. Mozo ran a long and open design exercise for a CA policy, which specifies that each CA requires an audit [1]. CAcert hasn't got an audit [2]. Mozo did indeed work quite hard to give CAcert and others some more open access to the process. One could debate the wisdom of having an audit at all, or ascribe the motives to politics, or whatever [3] ... in the end, Mozo moved a considerable distance by opening up the process to non-financial-audit firms and to criteria from non-consortium authors [4]. CAcert also now conducts an open process [5], so it is much easier to talk about the audit. It is well advanced on the policy side, only lacking one or two critical policies which are works-in-progress. Audits generally deliver reports that say things like "management has put in place procedures and policies..." so CAcert is in good shape here. Where the audit has stalled is on the systems side (and the missing policies are all on that side as well). CAcert will either solve their systems problems or die in the attempt. My current estimate is that if CAcert moves seriously to solve the systems problems, then it may have the audit by early 2009. If not, not. You can read more about it [6] or ask me or them or join their many mail lists, etc etc. iang [1] The process was led by Frank Hecker on the open mozo security maillist. I was part of that process, as was Duane (founder of CAcert), because it was an open process. http://www.mozilla.org/projects/security/certs/policy/ IMO, the Mozo CA policy project was a great case study in open security, and should be copied by others, including other Mozo security processes. [2] By way of disclosure, I am the auditor. Minutes of most recent published audit report: http://wiki.cacert.org/wiki/AuditPresentations [3] FTR I argued against the requirements for audits. [4] The case for audits was significantly weakened when rumours spread of audited CAs conducting MITMs on their own customers, and the logical claim that this was permitted under audit as long as it was disclosed, sort of, somewhere, maybe. This was crucial in shifting consensus to allow competition in audit criteria and auditors. [5] Due to direction from Greg Rose (retiring President) and a funding deal with NLnet that imposes frequent public reports. [6] http://wiki.cacert.org/wiki/Audit - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: TLS-SRP & TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
On Thu, Feb 07, 2008 at 08:47:20PM +1300, Peter Gutmann wrote: > Victor Duchovni <[EMAIL PROTECTED]> writes: > > >While Firefox should ideally be developing and testing PSK now, without > >stable libraries to use in servers and browsers, we can't yet expect anything > >to be released. > > Is that the FF devlopers' reason for holding back? Just wondering... why not > release it with TLS-PSK/SRP anyway (particularly with 3.0 being in the beta > stage, it'd be the perfect time to test new features), tested against existing > implementations, then at least it's ready for when server support appears. At > the moment we seem to be in a catch-22, servers don't support it because > browsers don't, and browsers don't support it because servers don't. I don't have any idea why or why not, but all they can release now is source code with #ifdef openssl >= 0.9.9 ... do PSK stuff ... #endif, with binaries (dynamically) linked against the default OpenSSL on the oldest supported release of each platform... For RedHat 4.x systems, for example, that means that binary packages use 0.9.7... Distributions that build their own Firefox from source may at some point have PSK (once they ship OpenSSL 0.9.9). I don't think we will see this available in many user's hands for 2-3 years after the code is written (fielding new systems to the masses takes a long time...). -- /"\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: TLS-SRP & TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
Victor Duchovni <[EMAIL PROTECTED]> writes: >While Firefox should ideally be developing and testing PSK now, without >stable libraries to use in servers and browsers, we can't yet expect anything >to be released. Is that the FF devlopers' reason for holding back? Just wondering... why not release it with TLS-PSK/SRP anyway (particularly with 3.0 being in the beta stage, it'd be the perfect time to test new features), tested against existing implementations, then at least it's ready for when server support appears. At the moment we seem to be in a catch-22, servers don't support it because browsers don't, and browsers don't support it because servers don't. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: TLS-SRP & TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
Frank Siebenlist <[EMAIL PROTECTED]> writes: >With the big browser war still going strong, wouldn't that provide fantastic >marketing opportunities for Firefox? There's always the problem of politics. You'd think that support for a free CA like CAcert would also provide fantastic marketing opportunities for free browser like Firefox, but this seems to be stalled pretty much idefinitely because since CAcert doesn't charge for certificates, including it in Firefox would upset the commercial CAs that do (there's actually a lot more to it than this, see the interminable flamewars on this topic on blogs and whatnot for more information). >If Firefox would support these secure password protocols, and the banks would >openly recommend their customers to use Firefox because its safer and >protects them better from phishing, that would be great publicity for >Firefox, draw more users, and force M$ to support it too in the long run... Here's a suggestion to list members: - If you know a Firefox developer, go to them and tell them that TLS-PSK and TLS-SRP support would be a fantastic selling point and would allow Firefox to trump IE in terms of resisting phishing, which might encourage banks to recommend it to users in place of IE. - If you know anyone with some clout at Microsoft, tell them that your organisation is thinking of mandating a switch to Firefox because IE doesn't support phish-resistant authentication like TLS-PSK/TLS-SRP, and since you have x million paying customers this won't look good for MS. - If you work for any banking regulators (for example the FFIEC), require failsafe authentication (in which the remote site doesn't get a copy of your credentials if the authentication fails) rather than the current two-factor auth (which has lead to farcical "two-factor" mechanisms like SiteKey). Oh, and don't tell them I put you up to this :-). Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: TLS-SRP & TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
On Wed, Feb 06, 2008 at 09:21:47AM -0800, Frank Siebenlist wrote: > With the big browser war still going strong, wouldn't that provide > fantastic marketing opportunities for Firefox? > > If Firefox would support these secure password protocols, and the banks > would openly recommend their customers to use Firefox because its safer > and protects them better from phishing, that would be great publicity > for Firefox, draw more users, and force M$ to support it too in the long > run... It is a bit early. OpenSSL 0.9.9 is not yet released. I wish OpenSSL releases were more frequent, and each added fewer features, allowing features to be released as they mature, this would also reduce pressure to add features to stable releases (which occasionally break binary compatibility, and lead to vendors back-porting fixes rather than deploying the next patch level of the stable release). While Firefox should ideally be developing and testing PSK now, without stable libraries to use in servers and browsers, we can't yet expect anything to be released. -- /"\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: TLS-SRP & TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
Peter Gutmann wrote: Frank Siebenlist <[EMAIL PROTECTED]> writes: That's actually a sad observation. I keep telling my colleagues that this technology is coming "any day now" to a browser near you - didn't realize that that there was no interest with the browser companies to add support for this... I know of a number of organisations (mostly governmental, but also some financial) in various countries who are really, really keen to get support for (as James Donald pointed out) cryptographically secured relationships (not requiring PKI would be a big feature) into browsers, but no-one knows who to beat over the head about it. The last group I talked to (banks) were hoping to use commercial pressure to get MS to add support for it in IE7^H^H8 at which point Firefox would be forced to follow, but it's a slow process. With the big browser war still going strong, wouldn't that provide fantastic marketing opportunities for Firefox? If Firefox would support these secure password protocols, and the banks would openly recommend their customers to use Firefox because its safer and protects them better from phishing, that would be great publicity for Firefox, draw more users, and force M$ to support it too in the long run... Why do the browser companies not care? What is the adoption issue? Still the dark cloud of patents looming over it? Not enough understanding about the benefits? (marketing) Economic reasons that we wouldn't buy anymore server certs? I think it's a combination of two factors: 1. Everyone knows that passwords are insecure, so it's not worth trying to do anything with them. (My counter-argument to this is that passwords are only insecure because protocol designers have chosen to make them insecure, see my previous post about the quaint 1970s-vintage hand-over-the-password model used by SSH and SSL/TLS). ...these protocol would even make the use of one-time-passwords more secure (no MITM exposure - phishing), and make them securely usable without any server-certs... 2. If you add failsafe authentication to browsers, CAs become redundant. (My counter-argument to this is to ask whether browser security exists in order to provide a business model for CAs or to protect users. Currently it seems to be the former, with EV certs being a prime example). I was afraid that this cynical argument would play a role... so the server-cert racketeering scheme has just been made more profitable through more expensive but equally "trustworthy" EV-certs, which makes it more difficult to introduce alternatives that don't fit into this "business model"... On the other hand, I'm sure that the marketeers will be able to sell server-certs together with those secure passwords protocols to the naive customers as it will be very difficult to explain why you do/don't need the certs and why it would more/less secure... -Frank. -- Frank Siebenlist [EMAIL PROTECTED] The Globus Alliance - Argonne National Laboratory - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: TLS-SRP & TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
Frank Siebenlist <[EMAIL PROTECTED]> writes: >That's actually a sad observation. > >I keep telling my colleagues that this technology is coming "any day now" to >a browser near you - didn't realize that that there was no interest with the >browser companies to add support for this... I know of a number of organisations (mostly governmental, but also some financial) in various countries who are really, really keen to get support for (as James Donald pointed out) cryptographically secured relationships (not requiring PKI would be a big feature) into browsers, but no-one knows who to beat over the head about it. The last group I talked to (banks) were hoping to use commercial pressure to get MS to add support for it in IE7^H^H8 at which point Firefox would be forced to follow, but it's a slow process. >Why do the browser companies not care? >What is the adoption issue? >Still the dark cloud of patents looming over it? >Not enough understanding about the benefits? (marketing) >Economic reasons that we wouldn't buy anymore server certs? I think it's a combination of two factors: 1. Everyone knows that passwords are insecure, so it's not worth trying to do anything with them. (My counter-argument to this is that passwords are only insecure because protocol designers have chosen to make them insecure, see my previous post about the quaint 1970s-vintage hand-over-the-password model used by SSH and SSL/TLS). 2. If you add failsafe authentication to browsers, CAs become redundant. (My counter-argument to this is to ask whether browser security exists in order to provide a business model for CAs or to protect users. Currently it seems to be the former, with EV certs being a prime example). There are probably other contributory reasons as well. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: TLS-SRP & TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
On Feb 1, 2008, at 9:34 PM, Ian G wrote: * Browser vendors don't employ security people as we know them on this mailgroup [...] But they are completely at sea when it comes to systemic security failings or designing new systems. I don't know about other browsers, but Mozilla's CSO-type is Window Snyder who I'd easily describe as a pretty top-notch "security person". -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: TLS-SRP & TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
At 09:34 PM 2/1/2008 +0100, Ian G wrote: * Browser vendors don't employ security people as we know them on this mailgroup, they employ cryptoplumbers. Completely different layer. These people are mostly good (and often very good) at fixing security bugs. We thank them for that! But they are completely at sea when it comes to systemic security failings or designing new systems. An excellent observation Ian!! I too have run into this mindset at enterprises with inhouse security teams (mostly in Silicon Valley). They focus on the nuts and bolts like producing/using cryptographic libaries, fixing security bugs in code or configuring network appliances to stop intrusions. But it is really hard to find any of them with decent experience or knowledge at the overall software/hardware/people system design level. They are often very smart and educated engineers. I find that there's this "mindless" focus on using groups of "security" standards, e.g PKI / LDAP / SSL type of combinations, etc. The DoD contractor firms seem to be a little bit better at recognizing the system level aspects of security, although they too are often blinded by the emphasis on "COTS" security products. - Alex -- Alex Alten [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: TLS-SRP & TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
Frank Siebenlist wrote: Why do the browser companies not care? I spent a few years trying to interest (at least) one browser vendor with looking at new security problems (phishing) and using the knowledge that we had to solve this (opportunistic cryptography). No luck whatsoever. My view of why it is impractical / impossible to interest the browser vendors in new ideas and new security might be summed as this: * Browser vendors operate a closed security shop. I think this is because of a combination of things. Mostly, all security shops are closed, and there aren't any good examples of open security shops (at least that I can think of). We see some outreach in the last few years (blogs or lists by some) but they are very ... protected, the moat is still there. * Browser vendors are influenced heavily by companies, which have strong agendas. Security programmers at the open browsers are often employed by big companies who want their security in. They are not interested in user security. Security programmers need jobs, they don't do this stuff for fun. So it is not as if you can blame them. * Browser vendors don't employ security people as we know them on this mailgroup, they employ cryptoplumbers. Completely different layer. These people are mostly good (and often very good) at fixing security bugs. We thank them for that! But they are completely at sea when it comes to systemic security failings or designing new systems. * Which also means it is rather difficult to have a conversation with them. For example, programmers don't know what governance is, so they don't know how to deal with PKI (which is governance with some certificate sugar), and they can't readily map a multi-party failure. OTOH, they know what code is, so if you code it up you can have a conversation. But if your conversation needs non-code elements ... glug glug... * Browser vendors work to a limited subset of the old PKI book. Unfortunately, the book itself isn't written, with consequent problems. So certain myths (like "all CAs must be the same") have arisen which are out of sync with the original PKI thinking ... and out of sync with reality ... but there is no easy way to deal with this because of the previous points. * Browser vendors may be on the hook for phishing. When you start to talk in terms like that, legal considerations make people go gooey and vague. Nobody in a browser vendor can have that conversation. Which is all to say ... it's not the people! It's the assumptions and history and finance and all other structural issues. That won't change until they are ready to change, and there are only limited things that outsiders can do. Just a personal opinion. iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
TLS-SRP & TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
Peter Gutmann wrote: "Perry E. Metzger" <[EMAIL PROTECTED]> writes: SSL involves digital certificates. Not really, James Donald/George W. Bush. It involves public keys, and it provides a channel by which X.509 certificates can be exchanged, Actually it doesn't even require X.509 certs. TLS-SRP and TLS-PSK provide mutual authentication of client and server without any use of X.509. The only problem has been getting vendors to support it, several smaller implementations support it, it's in the (still unreleased) OpenSSL 0.99, and the browser vendors don't seem to be interested at all, which is a pity because the mutual auth (the server has to prove possession of the shared secret before the client can connect) would significantly raise the bar for phishing attacks. (Anyone have any clout with Firefox or MS? Without significant browser support it's hard to get any traction, but the browser vendors are too busy chasing phantoms like EV certs). That's actually a sad observation. I keep telling my colleagues that this technology is coming "any day now" to a browser near you - didn't realize that that there was no interest with the browser companies to add support for this... Why do the browser companies not care? What is the adoption issue? Still the dark cloud of patents looming over it? Not enough understanding about the benefits? (marketing) Economic reasons that we wouldn't buy anymore server certs? -Frank. -- Frank Siebenlist [EMAIL PROTECTED] The Globus Alliance - Argonne National Laboratory smime.p7s Description: S/MIME Cryptographic Signature