Re: WYTM?
Ian Grigg wrote: Cryptography is a special product, it may appear to be working, but that isn't really good enough. Coincidence would lead us to believe that clear text or ROT13 were good enough, in the absence of any attackers. For this reason, we have a process. If the process is not followed, then coincidence doesn't help to save our bacon. It has to follow, for it to be valuable. If it doesn't follow, to treat it as anything other than a mere coincidence to be dismissed out of hand is leading us on to make other errors. I think that Matt Blaze said it fairly well. There are some security practices that in the recent past are now considered appalling. It's time to be a little bit appalled, and to recognise SSL for what it is - a job that survived not on its cryptographic merits, but through market and structural conditions at the time. SSL/TLS is not a complete security solution. It is a building block. It is a protocol for communication between two end points. As such, its threat model deals with threats involving that communication. It does not deal with the security of the end point, because if you can compromise the machine that the software trying to communicate is running on, then no protocol can provide you with any level of security. You might choose to argue that a communications protocol is not what we need, but that would have nothing to do with the threat model that SSL/TLS is designed around. It seems what you're criticizing here is the Netscape and Microsoft client/server HTTPS-based security solutions for electronic commerce. These are certainly built using SSL/TLS as a building block, but criticisms of their design have very little relevance for SSL/TLS itself. Here's specifically what the server does: When it is installed, it doesn't also install and start up the SSL server. You know that page that has the feather on? It should also start up on the SSL side as well, perhaps with a different colour. Specifically, when you install the server, it should create a self-signed certificate and use it. Straight away. No questions asked. Then, it becomes an administrator issue to replace that with a custom signed one, if the admin guy cares. This really has nothing to do with TLS. If you don't like the installation process for Apache, you could fix it and send the patches back, or you could write your own web server. There should be no dialogue at all. Going from HTTP to HTTPS/self signed is a mammoth increase in security. Why does the browser say it is less/not secure? Further, the popups are a bad way to tell the user what the security level is. The user can't grok them and easily mucks up on any complex qeustions. There needs to be a security display on the secured area that is more prominent and also more graded (caching numbers) than the current binary lock symbol. The security UI for netscape/mozilla has always been terrible. IMHO, designing a user-friendly UI for crypto stuff that doesn't compromise security has been (and continues to be) the greatest obstacle to getting people to use this stuff. -- Give a man a fire and he's warm for a day, but set | Tom Weinstein him on fire and he's warm for the rest of his life. | [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: SSL, client certs, and MITM (was WYTM?)
Ian Grigg wrote: Nobody doubts that it can occur, and that it *can* occur in practice. It is whether it *does* occur that is where the problem lies. This sort of statement bothers me. In threat analysis, you have to base your assessment on capabilities, not intentions. If an attack is possible, then you must guard against it. It doesn't matter if you think potential attackers don't intend to attack you that way, because you really don't know if that's true or not and they can always change their minds without telling you. -- Give a man a fire and he's warm for a day, but set | Tom Weinstein him on fire and he's warm for the rest of his life. | [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: SSL, client certs, and MITM (was WYTM?)
Ian Grigg wrote: Tom Weinstein wrote: In threat analysis, you have to base your assessment on capabilities, not intentions. If an attack is possible, then you must guard against it. It doesn't matter if you think potential attackers don't intend to attack you that way, because you really don't know if that's true or not and they can always change their minds without telling you. In threat analysis, you base your assessment on economics of what is reasonable to protect. It is perfectly valid to decline to protect against a possible threat, if the cost thereof is too high, as compared against the benefits. This is the reason that we cannot simply accept "the possible" as a basis for engineering of any form, let alone cryptography. And this is the reason why, if we can't measure it, then we are probably justified in assuming it's not a threat we need to worry about. The economic view might be a reasonable view for an end-user to take, but it's not a good one for a protocol designer. The protocol designer doesn't have an economic model for how end-users will end up using the protocol, and it's dangerous to assume one. This is especially true for a protocol like TLS that is intended to be used as a general solution for a wide range of applications. In some ways, I think this is something that all standards face. For any particular application, the standard might be less cost effective than a custom solution. But it's much cheaper to design something once that works for everyone off the shelf than it would be to custom design a new one each and every time. -- Give a man a fire and he's warm for a day, but set | Tom Weinstein him on fire and he's warm for the rest of his life. | [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: "SSL stops credit card sniffing" is a correlation/causality myth
Ian G wrote: But don't get me wrong - I am not saying that we should carry out a world wide pogrom on SSL/PKI. What I am saying is that once we accept that listening right now is not an issue - not a threat that is being actively dedended against - this allows us the wiggle room to deploy that infrastructure against phishing. Does that make sense? No, not really. Until you can show me an Internet Draft for a solution to phishing that requires that we give up SSL, I don't see any reason to do so. As a consumer, I'd be very reluctant to give up SSL for credit card transactions because I use it all the time and it makes me feel safer. What matters is now: what attacks are happening now. Does phishing exist, and does it take a lot of money? What can we do about it? If you don't know what we can do about phishing, why do you think that getting rid of SSL is a necessary first step? You seem to be putting the cart in front of the horse. -- Give a man a fire and he's warm for a day, but set | Tom Weinstein him on fire and he's warm for the rest of his life.| [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
DTLS for Java?
Does anyone know of a DTLS implementation for Java? I'd rather avoid using OpenSSL through JNI if I possibly can. -- Give a man a fire and he's warm for a day, but set | Tom Weinstein him on fire and he's warm for the rest of his life.| [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: TLS break
Perry E. Metzger wrote: I'll point out that in the midst of several current discussions, the news of the TLS protocol bug has gone almost unnoticed, even though it is by far the most interesting news of recent months. Perhaps because there have been so many false alarms over the years. Usually when I hear about an SSL MITM attack, it's really a browser UI spoofing attack with a bogus cert. This is the first attack against TLS that I consider to be the real deal. To really fix it is going to require a change to all affected clients and servers. Fortunately, Eric Rescorla has a protocol extension that appears to do the job. -- Give a man a fire and he's warm for a day, but set | Tom Weinstein him on fire and he's warm for the rest of his life.| twei...@pacbell.net - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
