Google Chrome has SNI because it uses WinHTTP for HTTPS connections
and WinHTTP supports SNI.
Adam
On Wed, Oct 22, 2008 at 5:33 AM, timeless [EMAIL PROTECTED] wrote:
On Tue, Oct 21, 2008 at 10:14 PM, Aaron Swartz [EMAIL PROTECTED] wrote:
You're thinking of SNI:
This is similar to the SSH model; the first time you connect,
you're expected to manually check by some means that you're
connecting to the right server. On subsequent connections, you
won't be bothered unless the key changes.
I'll concede that in most cases no-one actually verifies the
Zelechovski'; 'Andy Lyttle';
whatwg@lists.whatwg.org
Subject: RE: [whatwg] fixing the authentication problem
Somewhere, is there a definition of trust in this context? I say that in
all seriousness; it's not a facetious remark. I feel that
it might be useful.
Subject: Re: [whatwg] fixing the authentication problem
On Tue, Oct 21, 2008 at 4:35 PM, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
Sending any data, including, log-in data, through an unencrypted
connection
is greeted by a warning dialogue box in Internet Explorer.
Only the first time. IIRC
On Tue, Oct 21, 2008 at 10:14 PM, Aaron Swartz [EMAIL PROTECTED] wrote:
You're thinking of SNI:
http://en.wikipedia.org/wiki/Server_Name_Indication
which doesn't work in IE6, IE6, or Safari, making it less than useful
for anything serious.
anything proposed today to be added would appear
The most common way of authenticating to web applications is:
Client: GET /login
Server: htmlform method=post
Client: POST /login
user=joesmith01password=secret
Server: 200 OK
Set-Cookie: acct=joesmith01,2008-10-21,sj89d89asd89s8d
The obvious problem with this is that passwords are
On Tue, Oct 21, 2008 at 2:16 PM, Aaron Swartz [EMAIL PROTECTED] wrote:
The most common way of authenticating to web applications is:
Client: GET /login
Server: htmlform method=post
Client: POST /login
user=joesmith01password=secret
Server: 200 OK
Set-Cookie:
As I understand it: As an attacker, I can intercept that dXN...
string. Then I can simply make a login POST request myself at any time
in the future, sending the same encrypted string, and will get the
valid login cookies even though I don't know the password. So it
doesn't seem to work very
On Tue, Oct 21, 2008 at 9:36 AM, Eduard Pascual [EMAIL PROTECTED]wrote:
On Tue, Oct 21, 2008 at 2:16 PM, Aaron Swartz [EMAIL PROTECTED] wrote:
My proposal: add something to HTML5 so that the transaction looks like
this:
Client: GET /login
Server: htmlform method=post
On Tue, Oct 21, 2008 at 2:52 PM, Aaron Swartz [EMAIL PROTECTED] wrote:
As I understand it: As an attacker, I can intercept that dXN...
string. Then I can simply make a login POST request myself at any time
in the future, sending the same encrypted string, and will get the
valid login cookies
appears to be a very
good security regimen within the current constraints.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eduard Pascual
Sent: Tuesday, 2008 October 21 10:37
To: Aaron Swartz; whatwg@lists.whatwg.org
Subject: Re: [whatwg] fixing
On Tue, Oct 21, 2008 at 3:48 PM, Aaron Swartz [EMAIL PROTECTED] wrote:
There are three costs to SSL:
1. Purchasing a signed cert.
2. Configuring the web server.
3. The CPU time necessary to do the encryption.
1 could be fixed by less paranoid UAs, 2 could be fixed with better
software and
]
[mailto:[EMAIL PROTECTED] On Behalf Of Eduard Pascual
Sent: Tuesday, October 21, 2008 4:37 PM
To: Aaron Swartz; whatwg@lists.whatwg.org
Subject: Re: [whatwg] fixing the authentication problem
On Tue, Oct 21, 2008 at 2:16 PM, Aaron Swartz [EMAIL PROTECTED] wrote:
Some major web services redirect
Kornel Lesinski wrote:
...
Anyway, it doesn't make sense to duplicate all that functionality in
forms just because typical interface for HTTP authentication is ugly and
unusable. You can fix the interface, and there's proposal for it already
(from 1999!):
On Tue, Oct 21, 2008 at 4:35 PM, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
Sending any data, including, log-in data, through an unencrypted connection
is greeted by a warning dialogue box in Internet Explorer.
Only the first time. IIRC, the don't display this again checkbox is
checked by
To: Kristof Zelechovski; Andy Lyttle; whatwg@lists.whatwg.org
Subject: Re: [whatwg] fixing the authentication problem
On Tue, Oct 21, 2008 at 4:35 PM, Kristof Zelechovski [EMAIL PROTECTED] wrote:
Sending any data, including, log-in data, through an unencrypted
connection is greeted by a warning
On Wed, Oct 22, 2008 at 1:28 AM, WeBMartians [EMAIL PROTECTED] wrote:
Somewhere, is there a definition of trust in this context? I say that in
all seriousness; it's not a facetious remark. I feel that
it might be useful.
I can't speak for others, but just for myself: the way I understand
the
Eduard Pascual wrote:
Not similar at all: for unencrypted connections, you have the don't
bother me again option, in the form of an obvious checkbox; while
with self-signed certificates you are warned continuously; with the
only option to install the certificate on your system to trust it
(which
18 matches
Mail list logo
