Overclocking TLS/SSL (was: towards https everywhere and strict transport security)

Peter Gutmann asked.. > > Has anyone published any figures for this, CPU speed vs. network latency vs. > delay for crypto and the network? there's this (by Adam Langley).. Overclocking SSL http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html ..but it doesn't appea

Re: EFF/iSEC's SSL Observatory slides available

They tell me they will be releasing the data both raw and as a MySQL database, so you can learn interesting things just by writing SQL queries. > So, keep an eye on that page. The data is very useful. Many more > interesting conclusions remain to be drawn from the data; once it's out > (I'm told R

EFF/iSEC's SSL Observatory slides available

http://www.eff.org/observatory "We have downloaded a dataset of all of the publicly-visible SSL certificates, and will be making that data available to the research community in the near future." So, keep an eye on that page. The data is very useful. Many more interesting conclusions

TLS/SSL Survey (Ristic/Qualsys) (was: Re: A mighty fortress is our PKI)

Internet SSL Survey 2010 is here! (blog post) http://blog.ivanristic.com/2010/07/internet-ssl-survey-2010-is-here.html Actual report: Qualys Internet SSL Survey 2010 v1.6 (PDF, 3.2 MB) http://blog.ivanristic.com/Qualys_SSL_Labs-State_of_SSL_2010-v1.6.pdf =JeffH

Re: New Research Suggests That Governments May Fake SSL Certificates

On Mar 25, 2010, at 8:05 AM, Dave Kleiman wrote: March 24th, 2010 New Research Suggests That Governments May Fake SSL Certificates Technical Analysis by Seth Schoen http://www.eff.org/deeplinks/2010/03/researchers-reveal-likelihood-governments-fake-ssl ""Today two compute

Re: Law Enforcement Appliance Subverts SSL

s for not being interested in SSL and certificates when (as far as we can determine) 100% of all certificate errors seen by users are false positives. --dan - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cry

New Research Suggests That Governments May Fake SSL Certificates

March 24th, 2010 New Research Suggests That Governments May Fake SSL Certificates Technical Analysis by Seth Schoen http://www.eff.org/deeplinks/2010/03/researchers-reveal-likelihood-governments-fake-ssl ""Today two computer security researchers, Christopher Soghoian and Sid Stamm,

Law Enforcement Appliance Subverts SSL

http://www.wired.com/threatlevel/2010/03/packet-forensics/ "At a recent wiretapping convention however, security researcher Chris Soghoian discovered that a small company was marketing internet spying boxes to the feds designed to intercept those communications, without breaking the encryption,

Re: how to properly secure non-ssl logins (php + ajax)

On Feb 15, 2009, at 7:30 AM, Rene Veerman wrote: Recently, on both the jQuery(.com) and PHP mailinglists, a question has arisen on how to properly secure a login form for a non-ssl web- application. What's the threat model? users[user_id].user_login_hash = onewayHash(user_login

Re: how to properly secure non-ssl logins (php + ajax)

Hi, > Recently, on both the jQuery(.com) and PHP mailinglists, a question has > arisen on how to properly secure a login form for a non-ssl web-application. > But the replies have been "get ssl".. :( What makes you think these are ill-advised? > I disagree, and think tha

Re: how to properly secure non-ssl logins (php + ajax)

m) and PHP mailinglists, a question has > arisen on how to properly secure a login form for a non-ssl web-application. > But the replies have been "get ssl".. :( > > I disagree, and think that with a proper layout of authentication > architecture, one can really secure a login s

Re: how to properly secure non-ssl logins (php + ajax)

On Sun, 15 Feb 2009, Rene Veerman wrote: > Recently, on both the jQuery(.com) and PHP mailinglists, a question has > arisen on how to properly secure a login form for a non-ssl web-application. > But the replies have been "get ssl".. :( Unfortunately, they are right: get SS

Re: how to properly secure non-ssl logins (php + ajax)

- Original Message - From: "Rene Veerman" Sent: Sunday, February 15, 2009 4:30 AM Subject: how to properly secure non-ssl logins (php + ajax) I'm going to edit this, since I assume most of the code is completely irrelevant proposal: database stores Hash(password |

Re: how to properly secure non-ssl logins (php + ajax)

Rene Veerman writes: >Recently, on both the jQuery(.com) and PHP mailinglists, a question has >arisen on how to properly secure a login form for a non-ssl web-application. >But the replies have been "get ssl".. :( > >I disagree, and think that with a proper layout of aut

Re: how to properly secure non-ssl logins (php + ajax)

you initially setup the shared secret (aka the password). Without public key operations there is no good way to create accounts (unless this is done administratively, effectively "off line"). SSL of course can solve this (but you don't want to use SSL). You can also attempt to implement

how to properly secure non-ssl logins (php + ajax)

Hi. Recently, on both the jQuery(.com) and PHP mailinglists, a question has arisen on how to properly secure a login form for a non-ssl web-application. But the replies have been "get ssl".. :( I disagree, and think that with a proper layout of authentication architecture, one

More man-in-the-middle'd SSL sessions on the way

unencrypted state, privacy and security concerns arise. But vendors such as Riverbed, Juniper Networks and Blue Coat Systems can serve as a trusted "man in the middle" for optimizing data encrypted with SSL, which is commonly used in applications with Web interfaces and other

Re: SSL and Malicious Hardware/Software

-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

Re: SSL and Malicious Hardware/Software

For an unproxied site, I get a small green window with my own choice of text in it (e.g. "Gmail" if I'm visiting https://mail.google.com). If a proxy were to insert itself in the middle, that window would turn yellow, and the message would change to "(untrusted)". Assorted user studies suggest t

Re: SSL and Malicious Hardware/Software

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 Maliciou

SSL use

I've periodically posted that certain assumptions were made about "safe" SSL deployment for electronic commerce that were almost immediately invalidated. The original assumptions assumed that the enduser knew the binding between the webserve that they thot they were tal

Re: SSL and Malicious Hardware/Software

-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 way of alerting the user, I would be alerted immediately, becaus

Re: privacy expectations Was: SSL and Malicious Hardware/Software

On Wed, 30 Apr 2008 12:49:12 +0300 (IDT) Alexander Klimov <[EMAIL PROTECTED]> wrote: > > : > > Lance Corporal Jennifer Long was issued a government computer > to use on a government military network. When she was > suspected of violations of t

privacy expectations Was: SSL and Malicious Hardware/Software

On Tue, 29 Apr 2008, Jack Lloyd wrote: > > Expectations of privacy at work vary by jurisdiction and industry. In > > the US, and say in the financial services industry, any such expectations > > are groundless (IANAL). > > Most places I have worked (all in the US) explicitly required consent > to m

Re: SSL and Malicious Hardware/Software

pect a pretty > > reasonable level of privacy while using an SSL connection at work. > > Expectations of privacy at work vary by jurisdiction and industry. In > the US, and say in the financial services industry, any such expectations > are groundless (IANAL). Most places I h

Re: SSL and Malicious Hardware/Software

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

Re: SSL and Malicious Hardware/Software

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.

SSL and Malicious Hardware/Software

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 hardware, I find this appliance appa

Re: delegating SSL certificates

John Levine wrote: | Presumably the value they add is that they keep browsers from popping | up scary warning messages Apple's Mail.app checks certs on SSL-based mail server connections. It has the good - but also bad - feature that it *always* asks for user approval if it gets a ce

Re: delegating SSL certificates

[EMAIL PROTECTED] (Peter Gutmann) on Sunday, March 16, 2008 wrote: >[EMAIL PROTECTED] writes: > >>I would think this would be rather common, and I may have heard about certs >>that had authority to sign other certs in some circumstances... > >The desire to do it isn't uncommon, but it runs into pr

Re: delegating SSL certificates

On Mar 16, 2008, at 8:50 AM, John Levine wrote: So at the company I work for, most of the internal systems have expired SSL certs, or self-signed certs. Obviously this is bad. You only think this is bad because you believe CAs add some value. Presumably the value they add is that they

Re: delegating SSL certificates

>| Presumably the value they add is that they keep browsers from popping >| up scary warning messages >Apple's Mail.app checks certs on SSL-based mail server connections. >It has the good - but also bad - feature that it *always* asks for >user approval if it gets a cert it

Re: delegating SSL certificates

On Mar 17, 2008, at 10:06 AM, Leichter, Jerry wrote: | >> So at the company I work for, most of the internal systems have | >> expired SSL certs, or self-signed certs. Obviously this is bad. | > | >You only think this is bad because you believe CAs add some value. | | Pr

Re: delegating SSL certificates

| >> So at the company I work for, most of the internal systems have | >> expired SSL certs, or self-signed certs. Obviously this is bad. | > | >You only think this is bad because you believe CAs add some value. | | Presumably the value they add is that they keep browsers from

Re: [mm] delegating SSL certificates

On Mar 16, 2008, at 7:52 PM, Ben Laurie wrote: Dirk-Willem van Gulik wrote: So I'd argue that while x509, its CA's and its CRL's are a serious pain to deal** with, and seem add little value if you assume avery diligent and experienced operational team -- they do provide a useful 'procedur

Re: [mm] delegating SSL certificates

Dirk-Willem van Gulik wrote: So I'd argue that while x509, its CA's and its CRL's are a serious pain to deal** with, and seem add little value if you assume avery diligent and experienced operational team -- they do provide a useful 'procedural' framework and workflow-guide which is in itself v

Re: delegating SSL certificates

On Mar 16, 2008, at 12:32 PM, Ben Laurie wrote: [EMAIL PROTECTED] wrote: So at the company I work for, most of the internal systems have expired SSL certs, or self-signed certs. Obviously this is bad. You only think this is bad because you believe CAs add some value. SSH keys aren&#

Re: delegating SSL certificates

>> So at the company I work for, most of the internal systems have >> expired SSL certs, or self-signed certs. Obviously this is bad. > >You only think this is bad because you believe CAs add some value. Presumably the value they add is that they keep browsers from poppin

Re: delegating SSL certificates

[EMAIL PROTECTED] wrote: So at the company I work for, most of the internal systems have expired SSL certs, or self-signed certs. Obviously this is bad. You only think this is bad because you believe CAs add some value. SSH keys aren't signed and don't expire. Is that bad

Re: delegating SSL certificates

[EMAIL PROTECTED] writes: >I would think this would be rather common, and I may have heard about certs >that had authority to sign other certs in some circumstances... The desire to do it isn't uncommon, but it runs into problems with PKI religious dogma that only a CA can ever issue a certificat

Re: delegating SSL certificates

[EMAIL PROTECTED] wrote: So at the company I work for, most of the internal systems have expired SSL certs, or self-signed certs. Obviously this is bad. Sorta. TLS gets along with self signed just fine though, and obviously you can choose to accept a root or unsigned cert on a per-client

Re: delegating SSL certificates

>Are there any options that don't involve adding a new root CA? Assuming your sites all use subdomains of your company domain, a wildcard cert for *.whatever might do the trick. It's relatively expensive, but you can use the same cert in all your servers. >I would think this would be rather comm

delegating SSL certificates

So at the company I work for, most of the internal systems have expired SSL certs, or self-signed certs. Obviously this is bad. I know that if we had IT put our root cert in the browsers, that we could then generate our own SSL certs. Are there any options that don't involve adding a new

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

Philipp Gühring wrote: I had the feeling that Microsoft wants to abandon the usage of client certificates completely, and move the people to CardSpace instead. But how do you sign your emails with CardSpace? CardSpace only does the realtime authentication part of the market ... It's not rocket

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

Thierry Moreau <[EMAIL PROTECTED]> writes: >At first, it seems neat. But then, looking at how it works in practice: the >client receives an e-mail notification soliciting him to click on a HTML link >and then enroll for a security certificate, the client is solicited exactly >like a phishing crimi

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

Leichter, Jerry wrote: While trying to find something else, I came across the following reference: Title: Sender driven certification enrollment system Document Type and Number: United States Patent 6651166 Link to this page: http://www.freepatentsonline.com/665116

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

Is anyone aware of any third-party usability studies on CardSpace, OpenID, ...?). I'm not. It would be a good opportunity for security usability researchers to contribute though. [0] I'm not sure whether putting "CardSpace" and "Liberty" in such close proximity in the above line was a

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

Imagine if a website could instruct your browser to transparently generate a public/private keypair for use with that website only and send the public key to that website. Then, any time that the user returns to that website, the browser would automatically use that private key to authentica

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

Philipp =?iso-8859-1?q?G=FChring?= <[EMAIL PROTECTED]> writes: >I had the feeling that Microsoft wants to abandon the usage of client >certificates completely, and move the people to CardSpace instead. While there's an obvious interpretation of that ("Microsoft want to lock everyone into CardSpac

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

On Feb 11, 2008, at 8:28 AM, Philipp Gühring wrote: I had the feeling that Microsoft wants to abandon the usage of client certificates completely, and move the people to CardSpace instead. But how do you sign your emails with CardSpace? CardSpace only does the realtime authentication part of

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

Hi, > Microsoft broke this in IE7... It is no longer possible to generate and > enroll a client cert from a CA not on the trusted root list. So private > label CAs can no longer enroll client certs. We have requested a fix, > so this may come in the future, but the damage is already done... > > Al

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

| By the way, it seems like one thing that might help with client certs | is if they were treated a bit like cookies. Today, a website can set | a cookie in your browser, and that cookie will be returned every time | you later visit that website. This all happens automatically. Imagine | if a we

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

re: http://www.garlic.com/~lynn/aadsm28.htm#30 Fixing SSL so lots of the AADS http://www.garlic.com/~lynn/x959.html#aads scenarios are that every place a password might appear, have a public key instead. for various of the cookie authentication operations ... also think kerberos tickets

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

On Sat, Feb 09, 2008 at 05:04:28PM -0800, David Wagner wrote: > By the way, it seems like one thing that might help with client certs > is if they were treated a bit like cookies. Today, a website can set > a cookie in your browser, and that cookie will be returned every time > you later visit th

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

On 2/9/08, David Wagner <[EMAIL PROTECTED]> wrote: > By the way, it seems like one thing that might help with client certs > is if they were treated a bit like cookies. I don't see how this helps with phishing. Phishers will just go after the password or other secrets used to authenticate a new sy

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

David Wagner <[EMAIL PROTECTED]> writes: >Tim Dierks writes: >>(there are totally different reasons that client certs aren't being >>widely adopted, but that's beside the point). > >I'd be interested in hearing your take on why SSL client certs aren'

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

David Wagner wrote: I'd be interested in hearing your take on why SSL client certs aren't widely adopted. It seems like they could potentially help with the phishing problem (at least, the problem of theft of web authenticators -- it obviously won't help with theft of SSNs).

Fixing SSL (was Re: Dutch Transport Card Broken)

Tim Dierks writes: >(there are totally different reasons that client certs aren't being >widely adopted, but that's beside the point). I'd be interested in hearing your take on why SSL client certs aren't widely adopted. It seems like they could potentially help wit

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

a recent reference Research unmasks anonymity networks http://www.techworld.com/security/news/index.cfm?newsID=11295 Research unmasks anonymity networks http://www.networkworld.com/news/2008/020108-research-unmasks-anonymity.html Research unmasks anonymity networks http://www.arnnet.com.au/index.

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

StealthMonger wrote: > They can't be as "anonymous as cash" if the party > being dealt with can be identified. And the party can > be identified if the transaction is "online, > real-time". Even if other clues are erased, there's > still traffic analysis in this case. > > What the offline paradi

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

>They can't be as "anonymous as cash" if the party being dealt with >can be identified. And the party can be identified if the >transaction is "online, real-time". Even if other clues are erased, >there's still traffic analysis in this case. If I show up at a store and pay cash for something eve

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

StealthMonger wrote: They can't be as "anonymous as cash" if the party being dealt with can be identified. And the party can be identified if the transaction is "online, real-time". Even if other clues are erased, there's still traffic analysis in this case. What the offline paradigm has goin

TCP, SSL, SSH, TLS, HTTP and other tools of mass...

The title on this post is not fair, I agree. The real question I want to ask is, "Do we ever get it *right* the first time?" Let's step outside cryptography to look at a possible answer and avoid the traps inherent in discussing current politics. From 1908 to 1927 more than 15 million Model Ts w

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

Anne & Lynn Wheeler <[EMAIL PROTECTED]> write: > one of my favorite exchanges from the mid-90s was somebody claiming > that adding digital certificates to the electronic payment > transaction infrastructure would bring it into the modern age. my > response was that it actually would regress the i

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

ey are incalculable, unknowable, and vary with the person you are talking to. So a superficial conclusion would be "don't use client certificates because of the privacy issues" although the issues are somewhat more complex than "PII revealed in SSL key exchange." As I say, the

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

ore servers out there authing with Digest, honestly. > Validated email addresses for spamming. Spear-phishing perhaps, ... > > > There are CA´s on this planet that put things like social security numbers > into certificates. > > Who? Seriously, that's pretty signif

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

t; although the issues are somewhat more complex than "PII revealed in SSL key exchange." As I say, they'll plug on, as they need to prove that the cert is worth issuing. It's a data point, no more, and it doesn't exactly answer your spec above. But I'm having

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

Dave Howe <[EMAIL PROTECTED]> writes: >SSL - Cludge thrown together by a browser manufacturer, To paraphrase Winston Churchill, "SSL is the worst secure-pipe protocol, except for all the others". Like most people here, I can find assorted nits to pick with it (mostly messa

Re: Fixing SSL

On Thu, 31 Jan 2008 03:04, [EMAIL PROTECTED] said: > If you want a "public" example of client certificate usage: > https://secure.cacert.org/ > (You need a (free) client certificate from www.CAcert.org to be able to > access Which has the problem that you may use any certifcate you ever created

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

tity theft problem in case the certificate contains personal > data > that can be used for identity theft I totally disagree that this is a material problem that is in any meaningful way impeding the use of SSL client certificates (there are totally different reasons that client certs aren'

RE: Fixing SSL (was Re: Dutch Transport Card Broken)

To add to the examples Philipp has mentioned, I've been closely involved in the design and implementation of a number of projects for the Spanish government using SSL + client certificates; indeed, the new Spanish ID card includes two certificates, one for authentication and the other for di

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

Philipp Gühring wrote: Hi, SSL key distribution and management is horribly broken, with the result that everyone winds up using plaintext when they should not. Yes, sending client certificates in plaintext while claiming that SSL/TLS is secure doesn´t work in a world of phishing and

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

gt; > If you have > > an actual credible security argument you should post it to > > [EMAIL PROTECTED] > > Do you think the the security arguments I summed up above qualify on the tls > list? It's an open list. Feel free to make these arguments. > Should I go into

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

client to anyone who doesn´t care about the public key. (There are applications that just use the DN+Issuer information that they normally extract out of the certificates, ...) But impersonation is just one threat out of the huge SSL/TLS threat-model. > Certificates > shouldn't contain se

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

problems, rather than using one as an excuse for not fixing the other. We need to fix the network assuming the node is going to be made safe, and fix the node assuming the network is going to be made safe. >> Does anyone have an idea how we can fix this flaw >> within SSL/TLS within a rea

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

Philipp Gühring wrote: I once implemented SSL over GSM data channel (without PPP and without TCP), and discovered that SSL needs better integrity protection than raw GSM delivers. (I am quite sure that´s why people normally run PPP over GSM channels ...) SSH has the same problems. It also

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

At Wed, 30 Jan 2008 17:59:51 -, Dave Korn wrote: > > On 30 January 2008 17:03, Eric Rescorla wrote: > > > >>> We really do need to reinvent and replace SSL/TCP, > >>> though doing it right is a hard problem that takes more > >>> than morning

RE: Fixing SSL (was Re: Dutch Transport Card Broken)

On 30 January 2008 17:03, Eric Rescorla wrote: >>> We really do need to reinvent and replace SSL/TCP, >>> though doing it right is a hard problem that takes more >>> than morning coffee. >> >> TCP could need some stronger integrity protection. 8 Bits of

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

Philipp Gühring wrote: Yes, sending client certificates in plaintext while claiming that SSL/TLS is secure doesn´t work in a world of phishing and identity theft anymore. We have the paradox situation that I have to tell people that they should use HTTPS with server-certificates and username

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

At Wed, 30 Jan 2008 11:25:04 +0100, Philipp Gühring wrote: > > Hi, > > > SSL key distribution and management is horribly broken, > > with the result that everyone winds up using plaintext > > when they should not. > > Yes, sending client certificates in plainte

Fixing SSL (was Re: Dutch Transport Card Broken)

Hi, > SSL key distribution and management is horribly broken, > with the result that everyone winds up using plaintext > when they should not. Yes, sending client certificates in plaintext while claiming that SSL/TLS is secure doesn´t work in a world of phishing and identity theft any

Re: SSL/TLS and port 587

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

Re: SSL/TLS and port 587

nications Act, but it has nothing to do with warrants. First, there is no confusion here; I was simply addressing both issues as in my original question to the list: The often expressed idea that SSL/TLS and port 587 are somehow able to prevent warrantless wiretapping and so on, or protect any p

Re: SSL/TLS and port 587

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

Re: SSL/TLS and port 587

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 "

Re: SSL/TLS and port 587

o". For examples on claiming that SSL/TLS can protect email privacy, That's not what I asked, of course. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS and port 587

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

Re: SSL/TLS and port 587

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 usefu

RE: SSL/TLS and port 587

. Well, yes: it would be misleading to claim that end-to-end security protects you against an insecure or hostile endpoint. But it's a truism, and it's not right to say that there is a security gap that is any part of the remit of SSL/TLS to alleviate; the insecurity - the untrusted

Re: SSL/TLS and port 587

* 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

Re: SSL/TLS and port 587

On Jan 22, 2008 10:38 AM, Ed Gerck <[EMAIL PROTECTED]> wrote: > 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 wire

Re: SSL/TLS and port 587

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

Paul Hoffman wrote: 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

Re: SSL/TLS and port 587

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

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 prev

Re: SSL/TLS and port 587

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

SSL/TLS and port 587

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 not supported by

Re: refactoring crypto handshakes (SSL in 3 easy steps)

[EMAIL PROTECTED] wrote: > The obvious way - doing a specific step just to verify > the handshake - is the kind of code-centric thinking > that I'm trying to avoid. I'm having trouble finding > the right words for it. Basically an encrypted > network protocol is a language in which a transmissio

Re: refactoring crypto handshakes (SSL in 3 easy steps)

[EMAIL PROTECTED] wrote: > I wonder if we here could develop a handshake that was > cryptographically secure, resistant to CPU DoS now, > and would be possible to adjust as we get faster at > doing crypto operations to reduce latency even > further. Basically an easy knob for balancing high > lat

Re: refactoring crypto handshakes (SSL in 3 easy steps)

dversary. Whether or not it matters depends on some contextual details. > (BTW, usually we also want the capability negotiation > to be secure; SSL simply exchanges MACs of all messages > once the key for MAC has been agreed on. Would this > add 0.5 or 1RTT? Or perhaps there's some clever

  1   2   3   4   >