Re: SSL security
Jaroslav Pinkava wrote: > > Where can I get the last informations about present SSL security status? > I seek more detailed information than contented in the following report: > > http://webdevelopersjournal.com/articles/is_ssl_dead.html That article describes an attack against the link between URLs and certificates. Neither Netscape nor MSIE are vulnerable to this attack. In fact, I know of no browser that is vulnerable to this attack. This article is mostly just a free advertisement for Digital Bond. David Wagner and Bruce Schneier have performed an excellent analysis of SSL 3.0 which is available from http://www.counterpane.com/ssl.html This paper is three years old now, but I believe it still accurately reflects current knowledge of SSL 3.0's security. The TLS working group has addressed some of the potential weaknesses mentioned in the paper and I'd encourage you to use TLS if you have that option. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | [EMAIL PROTECTED] transcending structure. -- The Tao of Programming |
Re: more re Encryption Technology Limits Eased
John Gilmore wrote: > > There's a vague and undefined term in the press leaks so far: > > One-Time Technical Review > > What does this mean? It appeared in some early crypto liberalization > bills floated in Congressional committees. Based on my previous experience with the export process, here's what I think this means: You have to tell the NSA what you're doing and let them think about it for a while. You'll have to answer any questions they have, but they aren't likely to ask for source code. It's not something you want to do the week before you ship. It's a process that's likely to take a couple months and involve more than one face to face meeting with NSA people. Of course it may mean something completely different. I've been surprised by what the NSA does more often than not. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | [EMAIL PROTECTED] transcending structure. -- The Tao of Programming |
Re: going around the crypto
Marcus Leech wrote: > > "Steven M. Bellovin" wrote: > > > > It's clearly not automatic, but I suspect it would work > > > User behaviour is the weak point here--while the browsers WILL notify > you that the cert is signed by a CA you don't recognize, they also > give you the option of accepting the cert, which most users will just > blindly accept. Netscape gives you a couple of options here--accept > the site cert for this session only, or accept it forever; I expect lots > of users will choose "forever", since that's simpler. Actually, since accepting it for the current session only is the default, that is what most people pick. Once they become familiar with the interface (and maybe actually read the dialogs) they do become more likely to just pick "forever". -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | [EMAIL PROTECTED] transcending structure. -- The Tao of Programming |
Re: going around the crypto
Michael Helm wrote: > > > > > The attacker could also present a certficate from a fake CA with an > > > > appropriate name -- say, "Netscape Security Services", or something that > > > Right. In which case Netscape brings up a different dialog which > > > says that the server certificate is signed by an unrecognized > > > CA. Again, you can proceed, but it's not like it's automatic. > > > > It's clearly not automatic, but I suspect it would work > > In many organizations which have attempted to do pki, > it is often the case that a home-made certificate authority > with a self-signed root CA certificate is created that issues > in-house certificates for servers, clients, or whatever. > But many of those orgs. have found distributing the root CA certificate > very problematical, with the result that these acceptance dialogs > alluded to above becomes routine to the user community. The first > time this happens you probably look at what the many pop up windows > are saying, puzzle over them, & even dial up the local help desk. The > tenth time you just hold down the mouse button & whip thru it. It's simply amazing how much disinformation there is floating around about this stuff. If the organization attempting to do PKI isn't incompetent, they burn their cert into the install package for the browser that they give to users, eliminating this problem altogether. Sorry if I'm starting to sound a bit strident. I know that Netscape's PKI isn't anywhere within sight of perfect, but it's better than a lot of people give it credit for. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | [EMAIL PROTECTED] transcending structure. -- The Tao of Programming |
Re: going around the crypto
"Steven M. Bellovin" wrote: > > The obvious protection is for users to check the certificate. Most users, of > course, don't even know what a certificate is, let alone what the grounds are > for accepting one. It would also help if servers used client-side > certificates for authentication, since the man-in-the-middle can't spoof > the user's certificate. But almost no servers do that. The user doesn't need to check the certificate. Certificates for HTTP servers contain the host name of the machine they certify. The web browser checks the hostname in the certificate against the hostname in the URL. All the user must do is check the hostname in the URL that is displayed on his screen. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | [EMAIL PROTECTED] transcending structure. -- The Tao of Programming |
Re: Security Lab To Certify Banking Applications (was Re: ECARM NEWS for July 23,1999 Second Ed.)
"William H. Geiger III" wrote: > > In <v0421012db3be70faae9c@[207.244.108.87]>, on 07/23/99 >at 03:20 PM, Robert Hettinga <[EMAIL PROTECTED]> said: > > >> The Financial Services Security Laboratory will open July 28 in > >> Reston, Va. The facility will be used to test software packages against > >> a set of standards for securing e-commerce and bill-payment > >> applications, as well as browsers and operating software. > >> > > Well I have my doubts on this. Either they refuse to certify Microsoft & > Netscape software and alienate 90% of the consumer market, or they do > certify them making their certification worthless. While they certainly couldn't certify any browser that included Java or JavaScript, what about certifying one with the caveat that these features be turned off? The vast majority of the security problems in Communicator have come from strange interactions between, and within the object models of, these two very powerful languages. The one notable exception is the fairly recent buffer overruns in some of the mail attachment code that was not properly reviewed. Of course, Windows NT (and IE which we all know is part of the OS) could be certified as long as it wasn't connected to a network, just as was done for their C2 certification. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | [EMAIL PROTECTED] transcending structure. -- The Tao of Programming |
Re: Relative use of SSLV3 versus SSLV2
"Marcus J. Ranum" wrote: > > Does anyone out there have any statistics about usage of > SSLV3 versus SSLV2? I'm trying to get a feeling for how much > product support there needs to be for V2 -- is there even > a significant user base for it anymore? Does anyone keep any > measures of version usage?? Unfortunately, use of SSL2 is still significant. Anyone using a Netscape Commerce Server 1.0 still only has SSL2. This includes a number of major ecommerce sites. I believe that the latest CommerceXpert server from Netscape/AOL includes SSL3. Anyone using a new version of Apache/SSL or Netscape Enterprise Server has SSL3. When I was at Netscape, we asked Forrester if they had any numbers on this stuff, and they told us that they weren't tracking it at that time. You might want to check with them again to see if they've started doing it. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | [EMAIL PROTECTED] transcending structure. -- The Tao of Programming |
Re: Clear Session ID in SSLV3
"Marcus J. Ranum" wrote: > > Does anyone have a pointer to why the session ID in SSLV3 is > in the clear, rather than encrypted? I'm sure there's a good > reason for it (audit? logging? other...?) but I'm trying to > pin down exactly why it was done that way. Can anyone point > me in the right direction? If it was encrypted, you couldn't use it to identify a session when resuming. Since that was the only reason for having a session ID in the first place, it wouldn't make any sense to encrypt it. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | [EMAIL PROTECTED] transcending structure. -- The Tao of Programming |
Re: Padlock Size was Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
Steve Mynott wrote: > > There used to be two keys I believe a little (weak) key and a larger (strong) > key. In the (patched to domestic US strength) version of Netscape I use > (Linux 4.07) the padlock is always the same size. It may be my version > is broken. > > Anyone with a legit. US browser confirm that this visual cue (icon > size) has been removed? Up through 3.0, we used a key with one tooth for weak crypto and a key with two teeth for strong crypto. In 4.0, the UI people changed it to a padlock. Although we complained bitterly, they never put in any visual distinction between weak and strong crypto, although most of the code to do it is still there. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | [EMAIL PROTECTED] transcending structure. -- The Tao of Programming |
Re: write code outside US (Re: so why is IETF stilling adding DES to protocols?)
This is the last I'm going to say on this topic. It takes too much energy, and I have real work to do. Adam Back wrote: > Tom Weinstein writes: > > But that's not all, I have heard it claimed that most of the browsers > in existance, inside and outside the US are 40 bit, many of the > webservers inside and outside are, with the net result that probably > 90+% of all SSL traffic is encrypted with 40 bit ciphers. This is because it's so difficult to get a domestic version. We tried very hard to get strong crypto out as far as we could, but we drew the line at what the law allowed. As a corporation, we had to be careful about stepping over that line, because we were at the mercy of the government to get export licenses. I'm very encouraged by the progress in the Bernstein case, and whenever we talked to the lawyers, that was always an issue. > I wonder why it never occured to anyone at Netscape to write their > crypto outside the US? (I'd have thought perhaps some of those > ex-cypherpunk types who we all know are/were working there in roles > such as the 'Electronic Munitions Specialist' etc. would have been > familiar with the concept) As a matter of fact, it did occur to us. It turned out that there were a lot of problems with doing it. It's a lot easier for a company like PGP to do it because their only product is the one they are giving away. The same goes for Sameer. For a company like Netscape that sells a wide variety of products, it's a lot harder. > I mean if Sameer can do it, and Sun Micro can do it, and RSADSI can do > it why can't Netscape? Not like Netscape is short of a few bob to > open an office somewhere. Sun caught all kinds of hell from the Commerce Department, too. If you aren't familiar with this, you should talk to some of the people who were involved. Even as it was, we were under a lot of scrutiny for SSLeay and Fortify, which we had nothing to do with. > Netscape, and many other US companies *have* been losing money to > non-US companies *because* the US companies have been putting 'export > grade crypto into their products'. I certainly won't argue with this because it's true. Just because we didn't fight it the way you might have wanted us to doesn't mean we weren't aware of the problem. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | [EMAIL PROTECTED] transcending structure. -- The Tao of Programming |
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
"William H. Geiger III" wrote: > > I am *strongly* in favor in disabling all export ciphersuites. There is > just no use for them. Netscrape, Micky$loth, & RSADSI may have no problem > selling false security to their customers, IMHO the OpenSSL group should > be above this. > > I really think that a quick end could be brought to the export issue if a > few people overseas sued these companies for fraud. I have no interest in starting a flame war with you about the value of exportable cryptography, but I'm stupid, so I'm going to open my mouth anyway. I think your view only makes sense if you are only interested in protecting yourself against entities who have $100,000 (or $50,000, or whatever) to build a DES cracking machine. If, on the other hand, you're also worried about 12 year old kids who pass around lists of credit card numbers, then exportable crypto is useful to you. While the first group may be more scary to you, most people only care about the second group. Which is not to say that you're wrong about your priorities, but other people, rightly or wrongly, have different ones. Despite your contempt for Netscape and Microsoft, they do, in fact, sell strong crypto products where they are able to. If the CEOs of these companies went to their boards of directors and told them that they were going blow off the entire international market because they didn't want to put export grade crypto into their products, they'd be out of their jobs faster than you could say "stockholder lawsuit." -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | [EMAIL PROTECTED] transcending structure. -- The Tao of Programming |
Re: A different take on Intel's RSA announcements
Alan Olsen wrote: > On Jan 20, 5:08pm, Tom Weinstein wrote: > > Subject: Re: A different take on Intel's RSA announcements > > Rob Lemos wrote: > > > > > http://www.zdnet.com/zdnn/stories/news/0,4586,2189721,00.html > > > > This just seems like FUD to me. ID numbers should help detect theft and > > fraud. They aren't going to compromise privacy. I expect it's going to > behave > > just like the debugging registers. Nobody is going to be able to get at your > > chip's ID without running software on your system. > > "What part of ActiveX do you not understand?" If you're running ActiveX, you deserve what you get. ActiveX can do a lot more evil things to you than steal your processor ID. > When you are running an application designed by a third party on your system, > how do you know if they are not accessing that information and leaking it via > some covert channel? You don't. You also don't know that they aren't dumping your registry the same way. If you care about this stuff, why are you running Windows? > Chip IDs will be used for the causes of evil as long as marketing has a hand in > the design process. (For the process of obtaining customer demographics of > course.) Not a far step from governments demanding the ability to track down > and stomp on those who violate their rules or just plain noseyness. (When you > have them by the Chip ID, their hearts and minds will follow.) > > Of course they have to run software on your system. This means that we just > have to worry about the software we run. I expect that this will give rise to > programs that will scan binaries looking for the chip ID instructions and > replacing them with nulls or something more "interesting". That sounds like a fine idea. My point was that chip IDs aren't intrinsically evil. They're just yet another thing that can be exploited by evil software. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | [EMAIL PROTECTED] transcending structure. -- The Tao of Programming |
Re: A different take on Intel's RSA announcements
Rob Lemos wrote: > http://www.zdnet.com/zdnn/stories/news/0,4586,2189721,00.html This just seems like FUD to me. ID numbers should help detect theft and fraud. They aren't going to compromise privacy. I expect it's going to behave just like the debugging registers. Nobody is going to be able to get at your chip's ID without running software on your system. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | [EMAIL PROTECTED] transcending structure. -- The Tao of Programming |
Re: What was the quid pro quo for Wassenaar countries?
John Gilmore wrote: > PS: I particularly like Ambassador Aaron's characterization that > this new development will help US industry, by censoring foreign crypto > publishers in the same way the US government censors US publishers. > A giant step forward for freedom and commerce everywhere, eh Mr. Aaron? > What an incredibly talented liar, I mean diplomat, he is. I agree. This is something that I found particularly offensive. "Really, we're doing it for your own good!" Feh. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | [EMAIL PROTECTED] transcending structure. -- The Tao of Programming |
