Re: SSL and Malicious Hardware/Software

2008-05-06 Thread Arcane Jill
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven M. Bellovin Sent: 03 May 2008 00:51 To: Arcane Jill Cc: cryptography@metzdowd.com Subject: Re: SSL and Malicious Hardware/Software I can't think of a great way of alerting the user, I would

Re: SSL and Malicious Hardware/Software

2008-05-03 Thread Steven M. Bellovin
On Fri, 2 May 2008 08:33:19 +0100 Arcane Jill [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Phillips Sent: 28 April 2008 23:13 To: Cryptography Subject: SSL and Malicious Hardware/Software I can't think of a great

Re: SSL and Malicious Hardware/Software

2008-04-29 Thread Victor Duchovni
On Mon, Apr 28, 2008 at 03:12:31PM -0700, Ryan Phillips wrote: What are people's opinions on corporations using this tactic? I can't think of a great way of alerting the user, but I would expect a pretty reasonable level of privacy while using an SSL connection at work. Expectations of

Re: SSL and Malicious Hardware/Software

2008-04-29 Thread Leichter, Jerry
On Mon, 28 Apr 2008, Ryan Phillips wrote: | Matt's blog post [1] gets to the heart of the matter of what we can | trust. | | I may have missed the discussion, but I ran across Netronome's 'SSL | Inspector' appliance [2] today and with the recent discussion on this | list regarding malicious

Re: SSL and Malicious Hardware/Software

2008-04-29 Thread Jack Lloyd
On Mon, Apr 28, 2008 at 10:03:38PM -0400, Victor Duchovni wrote: On Mon, Apr 28, 2008 at 03:12:31PM -0700, Ryan Phillips wrote: What are people's opinions on corporations using this tactic? I can't think of a great way of alerting the user, but I would expect a pretty reasonable level of

Re: SSL/TLS and port 587

2008-01-23 Thread sjk
Ed Gerck wrote: List, I would like to address and request comments on the use of SSL/TLS and port 587 for email security. The often expressed idea that SSL/TLS and port 587 are somehow able to prevent warrantless wiretapping and so on, or protect any private communications, is IMO simply

Re: SSL/TLS and port 587

2008-01-23 Thread Sidney Markowitz
Ed Gerck wrote, On 23/1/08 7:38 AM: The often expressed idea that SSL/TLS and port 587 are somehow able to prevent warrantless wiretapping and so on, or protect any private communications, is IMO simply not supported by facts. I would like to see some facts to support the assertion that the

Re: SSL/TLS and port 587

2008-01-23 Thread Florian Weimer
* Ed Gerck: The often expressed idea that SSL/TLS and port 587 are somehow able to prevent warrantless wiretapping and so on, or protect any private communications, is IMO simply not supported by facts. Huh? Have you got a source for that? This is he first time I've heard of such claims.

Re: SSL/TLS and port 587

2008-01-23 Thread Steven M. Bellovin
On Tue, 22 Jan 2008 10:38:24 -0800 Ed Gerck [EMAIL PROTECTED] wrote: List, I would like to address and request comments on the use of SSL/TLS and port 587 for email security. The often expressed idea that SSL/TLS and port 587 are somehow able to prevent warrantless wiretapping and so on,

Re: SSL/TLS and port 587

2008-01-23 Thread Paul Hoffman
At 10:38 AM -0800 1/22/08, Ed Gerck wrote: The often expressed idea that SSL/TLS and port 587 are somehow able to prevent warrantless wiretapping and so on, or protect any private communications, is IMO simply not supported by facts. Can you point to some sources of this often expressed idea?

RE: SSL/TLS and port 587

2008-01-23 Thread Dave Korn
On 22 January 2008 18:38, Ed Gerck wrote: It is misleading to claim that port 587 solves the security problem of email eavesdropping, and gives people a false sense of security. It is worse than using a 56-bit DES key -- the email is in plaintext where it is most vulnerable. Well, yes:

Re: SSL/TLS and port 587

2008-01-23 Thread Ed Gerck
Bodo Moeller wrote: You don't take into account the many users these days who use wireless Internet access from their laptop computers, typically essentially broadcasting all network data to whoever is sufficiently close and sufficiently nosy. Yes. Caveats apply but SSL/TLS is useful and

Re: SSL/TLS and port 587

2008-01-23 Thread Steven M. Bellovin
On Tue, 22 Jan 2008 21:49:32 -0800 Ed Gerck [EMAIL PROTECTED] wrote: As I commented in the second paragraph, an attack at the ISP (where SSL/TLS is of no help) has been the dominant threat -- and that is why one of the main problems is called warrantless wiretapping. Further, because US law

Re: SSL/TLS and port 587

2008-01-23 Thread Paul Hoffman
At 9:49 PM -0800 1/22/08, Ed Gerck wrote: Can you point to some sources of this often expressed idea? It seems like a pretty flimsy straw man. It is common with those who think that the threat model is traversing the public Internet. I'll take that as a no. For examples on claiming that

Re: SSL/TLS and port 587

2008-01-23 Thread Ed Gerck
Steven M. Bellovin wrote: On Tue, 22 Jan 2008 21:49:32 -0800 Ed Gerck [EMAIL PROTECTED] wrote: As I commented in the second paragraph, an attack at the ISP (where SSL/TLS is of no help) has been the dominant threat -- and that is why one of the main problems is called warrantless wiretapping.

Re: SSL/TLS and port 587

2008-01-23 Thread Steven M. Bellovin
On Wed, 23 Jan 2008 08:10:01 -0800 Ed Gerck [EMAIL PROTECTED] wrote: Steven M. Bellovin wrote: On Tue, 22 Jan 2008 21:49:32 -0800 Ed Gerck [EMAIL PROTECTED] wrote: As I commented in the second paragraph, an attack at the ISP (where SSL/TLS is of no help) has been the dominant threat

Re: SSL/TLS and port 587

2008-01-23 Thread Ed Gerck
Steven M. Bellovin wrote: You're confusing two concepts. Warrants apply to government behavior; terming something a wireless wiretap carries the clear implication of government action. Private action may or may not violate the wiretap act or the Stored Communications Act, but it has nothing to

Re: SSL/TLS and port 587

2008-01-23 Thread Victor Duchovni
On Tue, Jan 22, 2008 at 10:38:24AM -0800, Ed Gerck wrote: List, I would like to address and request comments on the use of SSL/TLS and port 587 for email security. The often expressed idea that SSL/TLS and port 587 are somehow able to prevent warrantless wiretapping and so on, or

Re: SSL certificates for SMTP

2007-05-24 Thread Peter Saint-Andre
Paul Hoffman wrote: At 6:34 PM +0200 5/23/07, Florian Weimer wrote: But no one is issuing certificates which are suitable for use with SMTP (in the sense that the CA provides a security benefit). No one? I thought that VeriSign and others did, at least a few years ago. FWIW, last year we

Re: SSL Server needs access to raw HTTP data (Request for adivce)

2007-01-16 Thread Richard Powell
On Sun, 2007-01-14 at 21:07 +0100, Erik Tews wrote: Am Samstag, den 13.01.2007, 19:03 -0800 schrieb Richard Powell: I was hoping someone on this list could provide me with a link to a tool that would enable me to dump the raw HTTP data from a web request that uses SSL/HTTPS. I have full

Re: SSL Server needs access to raw HTTP data (Request for adivce)

2007-01-16 Thread Richard Powell
On Sat, 2007-01-13 at 19:03 -0800, Richard Powell wrote: I was hoping someone on this list could provide me with a link to a tool that would enable me to dump the raw HTTP data from a web request that uses SSL/HTTPS. I have full access to the server, but not to the client, and I want to know

Re: SSL Server needs access to raw HTTP data (Request for adivce)

2007-01-16 Thread Richard Powell
Thanks for the responses. I found the solution thanks to one of the suggestions off this list. Basically, just setup stunnel to accept the encrypted stream and forward it to a clear server and then sniffed the stream. Thanks again Richard On Sat, 2007-01-13 at 19:03 -0800, Richard Powell

Re: SSL Server needs access to raw HTTP data (Request for adivce)

2007-01-14 Thread Erik Tews
Am Samstag, den 13.01.2007, 19:03 -0800 schrieb Richard Powell: I was hoping someone on this list could provide me with a link to a tool that would enable me to dump the raw HTTP data from a web request that uses SSL/HTTPS. I have full access to the server, but not to the client, and I want

Re: SSL (https, really) accelerators for Linux/Apache?

2007-01-04 Thread Anne Lynn Wheeler
for lots of topic drift about fast transactions and lightweight SSL (somewhat related to past assertions that majority of SSL use has been e-commerce related)... recent post in thread on secure financial transactions http://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high

Re: SSL (https, really) accelerators for Linux/Apache?

2007-01-02 Thread Victor Duchovni
On Tue, Jan 02, 2007 at 01:43:14PM -0500, John Ioannidis wrote: There is too much conflicting information out there. Can someone please recommend an SSL accelerator board that they have personally tested and used, that works with the 2.6.* kernels and the current release of OpenSSL, and is

Re: SSL (https, really) accelerators for Linux/Apache?

2007-01-02 Thread Scott Mustard
On Tue, 2 Jan 2007, John Ioannidis wrote: There is too much conflicting information out there. Can someone please recommend an SSL accelerator board that they have personally tested and used, that works with the 2.6.* kernels and the current release of OpenSSL, and is actually an

RE: SSL Cert Prices Notes

2006-08-11 Thread Trei, Peter
, August 09, 2006 1:05 AM To: John Gilmore Cc: cryptography@metzdowd.com Subject: Re: SSL Cert Prices Notes [...] Have you looked at StartCom? https://cert.startcom.org/ Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml

Re: SSL Cert Prices Notes

2006-08-10 Thread Damien Miller
On Mon, 7 Aug 2006, John Gilmore wrote: Here is the latest quick update on SSL Certs. It's interesting that generally prices have risen. Though ev1servers are still the best commercial deal out there. The good news is that CAcert seems to be posistioned for prime time debut, and you

Re: SSL Cert Prices Notes

2006-08-10 Thread Peter Saint-Andre
John Gilmore wrote: Date: Sun, 6 Aug 2006 23:37:30 -0700 (PDT) From: [EMAIL PROTECTED] Subject: SSL Cert Notes Howdy Hackers, Here is the latest quick update on SSL Certs. It's interesting that generally prices have risen. Though ev1servers are still the best commercial deal out

Re: SSL Cert Prices Notes

2006-08-10 Thread Thor Lancelot Simon
On Mon, Aug 07, 2006 at 05:12:45PM -0700, John Gilmore wrote: The good news is that CAcert seems to be posistioned for prime time debut, and you can't beat *Free*. :-) You certainly can, if slipshod practices end up _costing_ you money. Has CAcert stopped writing certificates with no DN

Re: SSL stops credit card sniffing is a correlation/causality myth

2005-06-02 Thread Tom Weinstein
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

Re: SSL stops credit card sniffing is a correlation/causality myth

2005-06-02 Thread Adam Shostack
On Tue, May 31, 2005 at 06:43:56PM -0400, Perry E. Metzger wrote: | | Ian G [EMAIL PROTECTED] writes: | Perhaps you are unaware of it because no one has chosen to make you | aware of it. However, sniffing is used quite frequently in cases where | information is not properly protected. I've

Re: SSL stops credit card sniffing is a correlation/causality myth

2005-06-02 Thread Ian G
Ahh-oops! That particular reply was scrappily written late at night and wasn't meant to be sent! Apologies belatedly, I'd since actually come to the conclusion that Steve's statement was strictly correct, in that we won't ever *see* sniffing because SSL is in place, whereas I interpreted this

Re: SSL stops credit card sniffing is a correlation/causality myth

2005-06-02 Thread Ian G
On Thursday 02 June 2005 11:33, Birger Tödtmann wrote: Am Mittwoch, den 01.06.2005, 15:23 +0100 schrieb Ian G: [...] For an example of the latter, look at Netcraft. This is quite serious - they are putting out a tool that totally bypasses PKI/SSL in securing browsing. Is it insecure?

Re: SSL stops credit card sniffing is a correlation/causality myth

2005-06-02 Thread Anne Lynn Wheeler
Adam Shostack wrote: So, that may be the case when you're dealing with an SSL accelerator, but there are lots of other cases, say, implementing daabase security rules, or ensuring that non-transactional lookups are logged, which are harder to argue for, take more time and energy to implement,

Re: SSL stops credit card sniffing is a correlation/causality myth

2005-06-01 Thread Daniel Carosone
On Tue, May 31, 2005 at 06:43:56PM -0400, Perry E. Metzger wrote: So we need to see a Choicepoint for listening and sniffing and so forth. No, we really don't. Perhaps we do - not so much as a source of hard statistical data, but as a source of hard pain. People making (uninformed or

Re: SSL stops credit card sniffing is a correlation/causality myth

2005-06-01 Thread Perry E. Metzger
Daniel Carosone [EMAIL PROTECTED] writes: On Tue, May 31, 2005 at 06:43:56PM -0400, Perry E. Metzger wrote: So we need to see a Choicepoint for listening and sniffing and so forth. No, we really don't. Perhaps we do - not so much as a source of hard statistical data, but as a source of

Re: SSL stops credit card sniffing is a correlation/causality myth

2005-06-01 Thread Ian G
On Wednesday 01 June 2005 10:35, Birger Tödtmann wrote: Am Dienstag, den 31.05.2005, 18:31 +0100 schrieb Ian G: [...] As an alternate hypothesis, credit cards are not sniffed and never will be sniffed simply because that is not economic. If you can hack a database and lift 10,000++

Re: SSL stops credit card sniffing is a correlation/causality myth

2005-06-01 Thread Ian G
On Tuesday 31 May 2005 23:43, Perry E. Metzger wrote: Ian G [EMAIL PROTECTED] writes: Just on the narrow issue of data - I hope I've addressed the other substantial points in the other posts. The only way we can overcome this issue is data. You aren't going to get it. The companies that get

Re: SSL stops credit card sniffing is a correlation/causality myth

2005-06-01 Thread Ian G
Hi Birger, Nice debate! On Wednesday 01 June 2005 13:52, Birger Tödtmann wrote: Am Mittwoch, den 01.06.2005, 12:16 +0100 schrieb Ian G: [...] The point is this: you *could* turn off SSL and it wouldn't make much difference to actual security in the short term at least, and maybe not

Re: SSL stops credit card sniffing is a correlation/causality myth

2005-06-01 Thread Ian G
On Tuesday 31 May 2005 19:38, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Ian G writes: On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], James A. Donald writes: -- PKI was designed to defeat man in the middle attacks based on network

Re: SSL stops credit card sniffing is a correlation/causality myth

2005-05-31 Thread Steven M. Bellovin
In message [EMAIL PROTECTED], Ian G writes: On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], James A. Donald writes: -- PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a

Re: SSL stops credit card sniffing is a correlation/causality myth

2005-05-31 Thread Perry E. Metzger
Ian G [EMAIL PROTECTED] writes: On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote: The next part of this is circular reasoning. We don't see network sniffing for credit card numbers *because* we have SSL. I think you meant to write that James' reasoning is circular, but strangely,

Re: SSL stops credit card sniffing is a correlation/causality myth

2005-05-31 Thread Anne Lynn Wheeler
Steven M. Bellovin wrote: Given the prevalance of password sniffers as early as 1993, and given that credit card number sniffing is technically easier -- credit card numbers will tend to be in a single packet, and comprise a self-checking string, I stand by my statement. the major exploits

Re: SSL stops credit card sniffing is a correlation/causality myth

2005-05-31 Thread Ian G
On Tuesday 31 May 2005 21:03, Perry E. Metzger wrote: Ian G [EMAIL PROTECTED] writes: On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote: The next part of this is circular reasoning. We don't see network sniffing for credit card numbers *because* we have SSL. I think you meant to

Re: SSL stops credit card sniffing is a correlation/causality myth

2005-05-31 Thread Perry E. Metzger
Ian G [EMAIL PROTECTED] writes: Perhaps you are unaware of it because no one has chosen to make you aware of it. However, sniffing is used quite frequently in cases where information is not properly protected. I've personally dealt with several such situations. This leads to a big issue.

and constrained subordinate CA costs? (Re: SSL Cert prices ($10 to $1500, you choose!))

2005-03-25 Thread Adam Back
The URL John forwarded gives survey of prices for regular certs and subdomain wildcard certs/super certs (ie *.mydomain.com all considered valid with respect to a single cert). Does anyone have info on the cost of sub-ordinate CA cert with a name space constraint (limited to issue certs on

Re: SSL/TLS passive sniffing

2005-01-06 Thread Werner Koch
On Wed, 5 Jan 2005 08:49:36 +0800, Enzo Michelangeli said: That's basically what /dev/urandom does, no? (Except that it has the undesirable side-effect of depleting the entropy estimate maintained inside the kernel.) This entropy depletion issue keeps coming up every now and then, but I

Re: SSL/TLS passive sniffing

2005-01-04 Thread John Denker
I wrote: If the problem is a shortage of random bits, get more random bits! Florian Weimer responded: We are talking about a stream of several kilobits per second on a busy server (with suitable mailing lists, of course). This is impossible to obtain without special hardware. Not very special, as

Re: SSL/TLS passive sniffing

2005-01-04 Thread Greg Rose
At 22:51 2004-12-22 +0100, Florian Weimer wrote: * John Denker: Florian Weimer wrote: Would you recommend to switch to /dev/urandom (which doesn't block if the entropy estimate for the in-kernel pool reaches 0), and stick to generating new DH parameters for each connection, No, I wouldn't.

Re: SSL/TLS passive sniffing

2004-12-22 Thread Florian Weimer
* Victor Duchovni: The third mode is quite common for STARTTLS with SMTP if I am not mistaken. A one day sample of inbound TLS email has the following cipher frequencies: 8221(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) 6529(using TLSv1 with cipher

Re: SSL/TLS passive sniffing

2004-12-22 Thread John Denker
Florian Weimer wrote: Would you recommend to switch to /dev/urandom (which doesn't block if the entropy estimate for the in-kernel pool reaches 0), and stick to generating new DH parameters for each connection, No, I wouldn't. or ... generate them once per day and use it for several connections?

Re: SSL/TLS passive sniffing

2004-12-22 Thread Victor Duchovni
On Sun, Dec 19, 2004 at 05:24:59PM +0100, Florian Weimer wrote: * Victor Duchovni: The third mode is quite common for STARTTLS with SMTP if I am not mistaken. A one day sample of inbound TLS email has the following cipher frequencies: 8221(using TLSv1 with cipher

Re: SSL/TLS passive sniffing

2004-12-22 Thread Florian Weimer
* Victor Duchovni: The Debian folks have recently stumbled upon a problem in this area: Generating the ephemeral DH parameters is expensive, in terms of CPU cycles, but especailly in PRNG entropy. The PRNG part means that it's not possible to use /dev/random on Linux, at least on servers.

Re: SSL/TLS passive sniffing

2004-12-05 Thread Dirk-Willem van Gulik
On Wed, 1 Dec 2004, Anne Lynn Wheeler wrote: the other attack is on the certification authorities business process Note that in a fair number of Certificate issuing processes common in industry the CA (sysadmin) generates both the private key -and- certificate, signs it and then exports both

RE: SSL/TLS passive sniffing

2004-12-05 Thread Anton Stiglic
This sounds very confused. Certs are public. How would knowing a copy of the server cert help me to decrypt SSL traffic that I have intercepted? I found allot of people mistakenly use the term certificate to mean something like a pkcs12 file containing public key certificate and private key.

Re: SSL/TLS passive sniffing

2004-12-05 Thread Anne Lynn Wheeler
Anton Stiglic wrote: I found allot of people mistakenly use the term certificate to mean something like a pkcs12 file containing public key certificate and private key. Maybe if comes from crypto software sales people that oversimplify or don't really understand the technology. I don't know, but

RE: SSL/TLS passive sniffing

2004-12-01 Thread Ben Nagy
OK, Ian and I are, rightly or wrongly, on the same page here. Obviously my choice of the word certificate has caused confusion. [David Wagner] This sounds very confused. Certs are public. How would knowing a copy of the server cert help me to decrypt SSL traffic that I have intercepted?

RE: SSL/TLS passive sniffing

2004-12-01 Thread ben
-Original Message- From: Eric Rescorla [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 01, 2004 7:01 AM To: [EMAIL PROTECTED] Cc: Ben Nagy; [EMAIL PROTECTED] Subject: Re: SSL/TLS passive sniffing Ian Grigg [EMAIL PROTECTED] writes: [...] However could one do a Diffie

Re: SSL/TLS passive sniffing

2004-12-01 Thread Eric Rescorla
[EMAIL PROTECTED] writes: -Original Message- From: Eric Rescorla [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 01, 2004 7:01 AM To: [EMAIL PROTECTED] Cc: Ben Nagy; [EMAIL PROTECTED] Subject: Re: SSL/TLS passive sniffing Ian Grigg [EMAIL PROTECTED] writes: [...] However

Re: SSL/TLS passive sniffing

2004-11-30 Thread Ian Grigg
Ben raises an interesting thought: There was some question about whether this is possible for connections that use client-certs, since it looks to me from the spec that those connections should be using one of the Diffie Hellman cipher suites, which is obviously not vulnerable to a passive

Re: SSL/TLS passive sniffing

2004-11-30 Thread Ian Grigg
Ian Grigg writes: I note that disctinction well! Certificate based systems are totally vulnerable to a passive sniffing attack if the attacker can get the key. Whereas Diffie Hellman is not, on the face of it. Very curious... No, that is not accurate. Diffie-Hellman is also insecure if the

Re: SSL accel cards

2004-05-26 Thread Jun-ichiro itojun Hagino
Does anyone know of an SSL acceleration card that actually works under Linux/*BSD? I've been looking at vendor web pages (AEP, Rainbow, etc), and while they all claim to support Linux, Googling around all I find are people saying Where can I get drivers? The ones vendor shipped only work on

Re: SSL accel cards

2004-05-26 Thread Anton Stiglic
Does anyone know of an SSL acceleration card that actually works under Linux/*BSD? I successfully used a Broadcom PCI card on a Linux (don't remember what Linux and kernel version, this was close to 2 years ago). If I remember correctly it was the BCM5820 processor I used

RE: SSL accel cards

2004-05-25 Thread Grant Goodale
We've had great luck with the nFast and nForce lines of ssl accelerators from nCipher under Red Hat: http://www.ncipher.com Depending on which model you choose, you can get anywhere from 150 to 1600 key ops/sec. HTH, G -- Grant Goodale

Re: SSL, client certs, and MITM (was WYTM?)

2003-11-12 Thread Ian Grigg
Tom Weinstein wrote: 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

Re: SSL, client certs, and MITM (was WYTM?)

2003-11-12 Thread Peter Gutmann
Perry E. Metzger [EMAIL PROTECTED] writes: TLS is just a pretty straightforward well analyzed protocol for protecting a channel -- full stop. It can be used in a wide variety of ways, for a wide variety of apps. It happens to allow you to use X.509 certs, but if you really hate X.509, define an

Re: SSL, client certs, and MITM (was WYTM?)

2003-11-12 Thread Anton Stiglic
- Original Message - From: Tom Otvos [EMAIL PROTECTED] As far as I can glean, the general consensus in WYTM is that MITM attacks are very low (read: inconsequential) probability. I'm not certain this was the consensus. We should look at the scenarios in which this is possible, and

RE: SSL, client certs, and MITM (was WYTM?)

2003-11-12 Thread Anne Lynn Wheeler
Internet groups starts anit-hacker initiative http://www.computerweekly.com/articles/article.asp?liArticleID=125823liArti cleTypeID=1liCategoryID=2liChannelID=22liFlavourID=1sSearch=nPage=1 one of the threats discussed in the above is the domain name ip-address take-over mentioned previously

Re: SSL, client certs, and MITM (was WYTM?)

2003-11-12 Thread David Honig
At 07:11 PM 10/22/03 -0400, Perry E. Metzger wrote: Indeed. Imagine if we waited until airplanes exploded regularly to design them so they would not explode, or if we had designed our first suspension bridges by putting up some randomly selected amount of cabling and seeing if the bridge

Re: SSL, client certs, and MITM (was WYTM?)

2003-11-12 Thread Anton Stiglic
I'm not sure how you come to that conclusion. Simply use TLS with self-signed certs. Save the cost of the cert, and save the cost of the re-evaluation. If we could do that on a widespread basis, then it would be worth going to the next step, which is caching the self-signed certs, and

Re: SSL, client certs, and MITM (was WYTM?)

2003-10-23 Thread David Wagner
Thor Lancelot Simon wrote: Can you please posit an *exact* situation in which a man-in-the-middle could steal the client's credit card number even in the presence of a valid server certificate? Sure. If I can assume you're talking about SSL/https as it is typically used in ecommerce today,

Re: SSL, client certs, and MITM (was WYTM?)

2003-10-22 Thread Ian Grigg
Tom Otvos wrote: As far as I can glean, the general consensus in WYTM is that MITM attacks are very low (read: inconsequential) probability. Is this *really* true? The frequency of MITM attacks is very low, in the sense that there are few or no reported occurrences. This makes it a

RE: SSL, client certs, and MITM (was WYTM?)

2003-10-22 Thread Tom Otvos
So what purpose would client certificates address? Almost all of the use of SSL domain name certs is to hide a credit card number when a consumer is buying something. There is no requirement for the merchant to identify and/or authenticate the client the payment infrastructure

Re: SSL, client certs, and MITM (was WYTM?)

2003-10-22 Thread John S. Denker
On 10/22/2003 04:33 PM, Ian Grigg wrote: The frequency of MITM attacks is very low, in the sense that there are few or no reported occurrences. We have a disagreement about the facts on this point. See below for details. This makes it a challenge to respond to in any measured way. We have a

RE: SSL, client certs, and MITM (was WYTM?)

2003-10-22 Thread Anne Lynn Wheeler
At 05:08 PM 10/22/2003 -0400, Tom Otvos wrote: The CC number is clearly not hidden if there is a MITM. I think the I got my money so who cares where it came from argument is not entirely a fair representation. Someone ends up paying for abuses, even if it is us in CC fees, otherwise why

RE: SSL, client certs, and MITM (was WYTM?)

2003-10-22 Thread Tom Otvos
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. Or, whether it gets reported if it does occur. The question is one of costs and benefits - how much should we spend to defend against this attack? How

Re: SSL, client certs, and MITM (was WYTM?)

2003-10-22 Thread David Wagner
Tom Otvos wrote: As far as I can glean, the general consensus in WYTM is that MITM attacks are very low (read: inconsequential) probability. Is this *really* true? I'm not aware of any such consensus. I suspect you'd get plenty of debate on this point. But in any case, widespread exploitation of

Re: SSL, client certs, and MITM (was WYTM?)

2003-10-22 Thread Perry E. Metzger
Ian Grigg [EMAIL PROTECTED] writes: 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. The question is one of costs and benefits - how much should we spend to defend against this attack? How much do we save

Re: SSL, client certs, and MITM (was WYTM?)

2003-10-22 Thread Thor Lancelot Simon
On Wed, Oct 22, 2003 at 05:08:32PM -0400, Tom Otvos wrote: So what purpose would client certificates address? Almost all of the use of SSL domain name certs is to hide a credit card number when a consumer is buying something. There is no requirement for the merchant to identify and/or

Re: SSL, client certs, and MITM (was WYTM?)

2003-10-22 Thread Perry E. Metzger
[EMAIL PROTECTED] (David Wagner) writes: Tom Otvos wrote: As far as I can glean, the general consensus in WYTM is that MITM attacks are very low (read: inconsequential) probability. Is this *really* true? I'm not aware of any such consensus. I will state that MITM attacks are hardly a

Re: SSL, client certs, and MITM (was WYTM?)

2003-10-22 Thread Ian Grigg
Tom Weinstein wrote: 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

Re: SSL, client certs, and MITM (was WYTM?)

2003-10-22 Thread Perry E. Metzger
Ian Grigg [EMAIL PROTECTED] writes: 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. The cost of MITM

RE: SSL, client certs, and MITM (was WYTM?)

2003-10-22 Thread Anne Lynn Wheeler
At 05:42 PM 10/22/2003 -0400, Tom Otvos wrote: Absolutely true. If the only effect of a MITM is loss of privacy, then that is certainly a lower-priority item to fix than some quick cash scheme. So the threat model needs to clearly define who the bad guys are, and what their motivations are.

Re: SSL, client certs, and MITM (was WYTM?)

2003-10-22 Thread Tom Weinstein
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

Re: SSL, client certs, and MITM (was WYTM?)

2003-10-22 Thread Ian Grigg
Perry E. Metzger wrote: Ian Grigg [EMAIL PROTECTED] writes: 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

Re: SSL, client certs, and MITM (was WYTM?)

2003-10-22 Thread Perry E. Metzger
Ian Grigg [EMAIL PROTECTED] writes: Perry E. Metzger wrote: The cost of MITM protection is, in practice, zero. Not true! The cost is from 10 million dollars to 100 million dollars per annum. Those certs cost money, Perry! They cost nothing at all. I use certs every day that I've

RE: SSL

2003-07-10 Thread Whyte, William
[ Jill ] Instead, I have a different question: Where can I learn about SSL? [ Ian ] PS: next step is Ferguson Schneier's recent book which has been described as how to re-invent SSL. This reminds me: the best tutorial on the security aspects of SSL 3.0 that I know of is the Counterpane

Re: SSL

2003-07-10 Thread Eric Rescorla
Ian Grigg [EMAIL PROTECTED] writes: Ian Grigg [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: Instead, I have a different question: Where can I learn about SSL? Most people seem to think the RFC is unreadable, so ... As in, could someone reccommend a good book, or online

Re: SSL

2003-07-10 Thread Radia Perlman - Boston Center for Networking
Re: Eric Rescorla's SSL and TLS book: Actually, the price should be $40 US. That's the price at Amazon. Actually on bookpool.com it's $31. And if you can buy something else at the same time, they have free shipping on anything over $40. And let me 3rd or 4th the comment that it's

Re: SSL

2003-07-10 Thread Eric Murray
On Thu, Jul 10, 2003 at 12:04:33PM +0100, [EMAIL PROTECTED] wrote: Instead, I have a different question: Where can I learn about SSL? As in, could someone reccommend a good book, or online tutorial, or something, somewhere, that explains it all from pretty much first principles, and leaves

Re: SSL

2003-07-10 Thread Ng Pheng Siong
On Thu, Jul 10, 2003 at 12:04:33PM +0100, [EMAIL PROTECTED] wrote: guess). However, the complexity of the OpenSSL library has me stumped. (Plus, it's Unix-centric. I'd like to turn it into a Visual Studio port so I could compile without needing cygwin, gcc, etc., but that's another story). It