Paul Hoffman wrote:
In many deployments of SSL first, then authenticate the user with a
password, the site consists of two or more machines. Many or most
high-traffic secure sites use SSL front-end systems to terminate the SSL
connection, then pass the raw HTTP back to one or more web servers
Read in an email from a website:
You'll need to send us your CC information via regular email or fax. I
would suggest splitting up your CC info if you send it to us via email in
two separate emails for security.
-
The
James A. Donald wrote:
For PKI to have all these wonderful benefits, everyone
needs his own certificate. But the masses have not come
to the party, in part because of the rather Orwellian
requirements. Obviously I cannot get a certificate
testifying that I am the one true James Donald,
Stephan Neuhaus wrote:
James A. Donald wrote:
[...]
That's because PSKs (as I have understood them) have storage and
management issues that CA certificates don't have, [...]
that the issue of how to exchange PSKs
securely in the first place is left as an exercise for the reader (good
Stephan Neuhaus [EMAIL PROTECTED] writes:
I think you're talking about me here,
Oh no, I wasn't focusing on any one person, it was a characterisation of the
general response from security people when this sort of thing is mentioned.
Long before the discussion on this list, there were already
Alaric Dailey [EMAIL PROTECTED] writes:
While I admit that PKI is flawed, I don't see anyway that PSK could used
effectively.
How are PSKs going to be shared in a secure way?
are we talking about generating a new key for every connection?
if so how do you validate the key?
if not, how do
Peter Gutmann wrote:
Alaric Dailey [EMAIL PROTECTED] writes:
While I admit that PKI is flawed, I don't see anyway that PSK could used
effectively.
How are PSKs going to be shared in a secure way?
are we talking about generating a new key for every connection?
if so how do you validate
Peter Gutmann wrote:
Alaric Dailey [EMAIL PROTECTED] writes:
In my opinion, PSK has the same problems as all symmetric encryption, its
great if you can share the secret securely, but distribution to the masses
makes it infeasible.
Exactly, PSK's are infeasible, and all those thousands of web
Alaric Dailey wrote:
ATMs would be infeasible if they were not a 2 factor authentication
system, and every day we see more cracks in the way that system is
implemented. Starting with the way the PSKs are shared.
http://news.bbc.co.uk/1/hi/technology/4183330.stm
ATMs use something you
Alaric Dailey wrote:
Thus ATMs and the weak 2 factor authentication system they use are
untrustworthy, I knew that already, but as I said, its better than not
having the multifactor authentication. The fact that many cards may be
used as credit card and you thus bypass the second factor, is a
On Tue, 30 Aug 2005, Peter Gutmann wrote:
- A non-spoofable means of password entry that only applies for TLS-PSK
passwords. In other words, something where a fake site can't trick the user
into revealing a TLS-PSK key.
This sounds like a solution replete with all the problems that
James A. Donald wrote:
But does not, in fact, prevent.
Let me rephrase that. Are we now at a point where we must admit that
PKI isn't going to happen for the Web and that we therefore must face
the rewriting of an unknown (but presumably large) number of lines of
code to accomodate PSKs?
At 9:39 AM +0200 9/1/05, Stephan Neuhaus wrote:
Are we now at a point where we must admit that PKI isn't going to happen
s/happen/happen in a widely useful fashion/
for the Web
s/Web/Web and email/
and that we therefore must face the rewriting of an unknown (but
presumably large)
If I may inject my humble opinion(that isn't necessarily a response to
this peticular email), I may not be as informed as some but
While I admit that PKI is flawed, I don't see anyway that PSK could
used effectively.
How are PSKs going to be shared in a secure way?
are we talking about
Alaric Dailey wrote:
If I may inject my humble opinion(that isn't necessarily a response to
this peticular email), I may not be as informed as some but
While I admit that PKI is flawed, I don't see anyway that PSK could used
effectively.
How are PSKs going to be shared in a secure
James A. Donald wrote:
--
From: [EMAIL PROTECTED] (Peter
Gutmann)
TLS-PSK fixes this problem by providing mutual
authentication of client and server as part of the key
exchange. Both sides demonstrate proof-of- possession
of the password (without actually communicating
On Wed, Aug 31, 2005 at 01:44:25PM +0100, Ian G wrote:
Not only is there this distance, it is duplicated
across all languages and all the different auth
regimes and also for homegrown password auth,
over every application! I'd wonder if given these
barriers it will ever be possible to get
From: --
From: Stephan Neuhaus
[EMAIL PROTECTED]
If I have understood the draft correctly, using PSKs
means that the server and the client have a shared
secret that they must communicate securely beforehand,
and that they use some form of ZKP to assure the other
James A. Donald [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] (Peter Gutmann)
TLS-PSK fixes this problem by providing mutual
authentication of client and server as part of the key
exchange. Both sides demonstrate proof-of- possession
of the password (without actually communicating the
Peter Gutmann wrote:
And that's it's killer feature: Although you can still be duped into handing
out your password to a fake site, you simply cannot connect securely without
prior mutual authentication of client and server if TLS-PSK is used.
If I have understood the draft correctly, using
--
From: Dave Howe [EMAIL PROTECTED]
2) Google got into the CA business; namely, all
GoogleMail owners suddenly found they could send and
receive S/Mime messages from their googlemail
accounts, using a certificate that just appeared and
was signed by the GoogleMail
Dave Howe [EMAIL PROTECTED] writes:
Nicolas Williams wrote:
Yes, a challenge-response password authentication protocol, normally
subject to off-line dictionary attacks by passive and active attackers
can be strengthened by throwing in channel binding to, say, a TLS
channel, such that: a)
Peter Gutmann wrote:
TLS-PSK fixes this problem by providing mutual authentication of client and
server as part of the key exchange. Both sides demonstrate proof-of-
possession of the password (without actually communicating the password), if
either side fails to do this then the TLS handshake
2005/8/29, Dave Howe [EMAIL PROTECTED]:
So, the solution to nobody using the existing (but adequate) solution is
another
existing (but barely implimented and also unused) solution?
I think the good solution is the one chosen by some bank ... :
In listening to this thread hearing all the hyperbole on both sides,
I would suggest that we may need more fuel to the fire.
There was a rump presentation at the recent Crypto on the use of
Ceremonies (which, pardon my misstatement in advance, is claimed to
be computer protocols with the
James A. Donald wrote:
SSL works in practice, X509 with CA certs does not work
in practice. People have been bullied into using it by
their browsers, but it does not give the protection
intended, because people do what is necessary to avoid
being nagged by browsers, not what is necessary to
Dave Howe wrote:
Indeed so - however, if Google makes it just work then there will be
a large swathe of people out there wondering what does this DIGITAL
SIGNATURE button do in gmail? plus a smaller subset who have google
talk and can perform secure e2e voip using x509 certs that they don't
Anne Lynn Wheeler wrote:
the major ISPs are already starting to provide a lot of security
software to their customers.
a very straight forward one would be if they provided public key
software ... to (generate if necessary) and register a public key in
lieu of password ... and also support the
I would appreciate your thoughts on WiKID. We use asymmetric keys to
encrypt PINs and one-time passcodes between a client and the server. The
server talks to various network clients using protocols such as LDAP,
Radius, or using our own SSL-tunneled wAuth protocol. We believe that
replacing
--
From: [EMAIL PROTECTED] (Peter
Gutmann)
TLS-PSK fixes this problem by providing mutual
authentication of client and server as part of the key
exchange. Both sides demonstrate proof-of- possession
of the password (without actually communicating the
password), if
Nicolas Williams wrote:
Yes, a challenge-response password authentication protocol, normally
subject to off-line dictionary attacks by passive and active attackers
can be strengthened by throwing in channel binding to, say, a TLS
channel, such that: a) passive attacks are not possible, b) MITMs
Dave Howe [EMAIL PROTECTED] writes:
Ian G wrote:
none of the above. Using SSL is the wrong tool
for the job.
For the one task mentioned - transmitting the username/password pair
to the server - TLS is completely appropriate. However, hash based
verification would seem to be more secure,
Steven M. Bellovin wrote:
Do I support e2e crypto? Of course I do! But the cost -- not the
computational cost; the management cost -- is quite high; you need
to get authentic public keys for all of your correspondents. That's
beyond the ability of most people.
I don't think it is that hard
Steven M. Bellovin wrote:
But this underscores one of my points: communications security is fine,
but the real problem is *information* security, which includes the
endpoint. (Insert here Gene Spafford's comment about the Internet,
park benches, cardboard shacks, and armored cars.)
*That*
Eric Rescorla wrote:
Most chat protocols (and Jabber in particular) are server-oriented
protocols. So, the SSL certificate in question isn't that of your
buddy but rather of your Jabber server.
Adam Back [EMAIL PROTECTED] writes:
Thats broken, just like the WAP GAP ... for security you want
Think end-to-end.. Even jabber has a way to encrypt messages
end-to-end using
user certificates (or PGP).
-derek
I am aware of Jabbers support for GPG/PGP, but did I miss their support
for user certificates? I have seen no indication of such support, what
client supports it?
Alaric
John Kelsey [EMAIL PROTECTED] writes:
Recently, Earthlink's webmail server certificate started showing up as
expired. (It obviously expired a long time ago; I suspect someone must have
screwed up in changing keys over or something, because the problem wasn't
happening up until recently.)
This is
Adam Back wrote:
Thats broken, just like the WAP GAP ... for security you want
end2end security, not a secure channel to an UTP (untrusted third
party)!
Well, in the Jabber/XMPP world you can run your own server (just as you
can in the email world). I see no harm in e2m channel encryption in
Alaric Dailey wrote:
I am aware of Jabbers support for GPG/PGP, but did I miss their support
for user certificates? I have seen no indication of such support, what
client supports it?
RFC 3923.
But no clients support that yet to my knowledge.
Peter
smime.p7s
Description: S/MIME
- Original Message -
From: Perry E. Metzger [EMAIL PROTECTED]
To: Adam Back [EMAIL PROTECTED]
Cc: Peter Saint-Andre [EMAIL PROTECTED]; cryptography@metzdowd.com
Sent: Friday, August 26, 2005 8:55 PM
Subject: Re: Another entry in the internet security hall of shame
[...]
Remember
In message [EMAIL PROTECTED], Adam Back writes:
Thats broken, just like the WAP GAP ... for security you want
end2end security, not a secure channel to an UTP (untrusted third
party)!
What is security? What are you trying to protect, and against whom?
I use Jabber extensively, and I utterly
On Fri, Aug 26, 2005 at 11:41:42AM -0400, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Adam Back writes:
Thats broken, just like the WAP GAP ... for security you want
end2end security, not a secure channel to an UTP (untrusted third
party)!
What is security? What are you
periodically, some of the PKI related comments remind me of some stories
about power production from the 70s.
some of the '70s energy stories focused on the different quality of
support for power generation technologies based on whether they were
institutional centric (and would be able to charge
On 8/26/05, Steven M. Bellovin [EMAIL PROTECTED] wrote:
...
If you don't trust your (or your correspondents') IM servers, it may be
a different situation. I haven't read Google's privacy policies for
IM; if it's anything like gmail, they're using automated tools that
look at your messages
Enzo Michelangeli wrote:
Remember that Jabber and similar protocols also trust servers to some
extent. Servers store and distribute valuable information like
presence data -- it is architecturally hard to do otherwise.
Well, not really: the buddies on the list can be located through a
Adam Back wrote:
Well I think security in IM, as in all comms security, means security
such that only my intended recipients can read the traffic. (aka e2e
security).
I don't think the fact that you personally don't care about the
confidentiality of your IM messages should argue for not doing
In message [EMAIL PROTECTED], Chris Kuethe writes:
On 8/26/05, Steven M. Bellovin [EMAIL PROTECTED] wrote:
...
If you don't trust your (or your correspondents') IM servers, it may be
a different situation. I haven't read Google's privacy policies for
IM; if it's anything like gmail, they're
In message [EMAIL PROTECTED], Adam Back writes:
On Fri, Aug 26, 2005 at 11:41:42AM -0400, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Adam Back writes:
Thats broken, just like the WAP GAP ... for security you want
end2end security, not a secure channel to an UTP (untrusted third
Ian G wrote:
none of the above. Using SSL is the wrong tool
for the job.
For the one task mentioned - transmitting the username/password pair to the
server - TLS is completely appropriate. However, hash based verification would
seem to be more secure, require no encryption overhead on the
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Peter Saint-Andre
Sent: Wednesday, August 24, 2005 4:56 PM
To: cryptography@metzdowd.com
Subject: Re: Another entry in the internet security hall of shame
Tim Dierks wrote:
[resending due to e
On 8/25/05, Trei, Peter [EMAIL PROTECTED] wrote:
Self-signed certs are only useful for showing that a given
set of messages are from the same source - they don't provide
any trustworthy information as to the binding of that source
to anything.
Which is just fine. Pseudonymity is good.
If,
At 9:42 AM -0400 8/25/05, Trei, Peter wrote:
Self-signed certs are only useful for showing that a given
set of messages are from the same source - they don't provide
any trustworthy information as to the binding of that source
to anything.
Oddly enough, the same could be said for a hierarchically
Trei, Peter wrote:
Ironically, Peter's message above kicked off warning
dialogs from MS Outlook, since it was signed using a keypair
signed with Peter's own self-signed root, which was not in
MSO's list of trusted roots.
You may trust CAcert's root more or less than a root that is trusted by
Trei, Peter wrote:
Self-signed certs are only useful for showing that a given
set of messages are from the same source - they don't provide
any trustworthy information as to the binding of that source
to anything.
Perfectly acceptable over chat, no? That is,
who else would you ask to confirm
Tim Dierks wrote:
[resending due to e-mail address / cryptography list membership issue]
On 8/24/05, Ian G [EMAIL PROTECTED] wrote:
Once you've configured iChat to connect to the Google Talk service, you may
receive a warning message that states your username and password will be
transferred
Ian G [EMAIL PROTECTED] writes:
Trei, Peter wrote:
Self-signed certs are only useful for showing that a given
set of messages are from the same source - they don't provide
any trustworthy information as to the binding of that source
to anything.
Perfectly acceptable over chat, no? That
In another routine event in the adventure known as
getting security to work in spite of the security,
I just received this ...
[fwd]
When creating a google talk compatible IM personality in Apple's iChat you
get the following warning on the Google Help pages:
-=-=-
12. Check the boxes next
Quoting Ian G [EMAIL PROTECTED]:
Once you've configured iChat to connect to the Google Talk service, you may
receive a warning message that states your username and password will be
transferred insecurely. This error message is incorrect; your username and
password will be safely transferred.
[resending due to e-mail address / cryptography list membership issue]
On 8/24/05, Ian G [EMAIL PROTECTED] wrote:
Once you've configured iChat to connect to the Google Talk service, you may
receive a warning message that states your username and password will be
transferred insecurely. This
Tim Dierks wrote:
[resending due to e-mail address / cryptography list membership issue]
On 8/24/05, Ian G [EMAIL PROTECTED] wrote:
Once you've configured iChat to connect to the Google Talk service, you may
receive a warning message that states your username and password will be
transferred
Tim Dierks wrote:
[resending due to e-mail address / cryptography list membership issue]
On 8/24/05, Ian G [EMAIL PROTECTED] wrote:
Once you've configured iChat to connect to the Google Talk service, you may
receive a warning message that states your username and password will be
transferred
Guys,
Recently, Earthlink's webmail server certificate started showing up as expired.
(It obviously expired a long time ago; I suspect someone must have screwed up
in changing keys over or something, because the problem wasn't happening up
until recently.) So, I contacted Earthlink's
62 matches
Mail list logo
