-----Original Message-----
From: Simon Josefsson [mailto:simon(_at_)josefsson(_dot_)org]
Sent: Tuesday, September 29, 2009 10:20 PM
To: Joseph Salowey (jsalowey)
Cc: Michael D'Errico; martin(_dot_)rex(_at_)sap(_dot_)com;
ietf(_at_)ietf(_dot_)org; tls(_at_)ietf(_dot_)org
Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis
(Transport Layer
"Joseph Salowey (jsalowey)" <jsalowey(_at_)cisco(_dot_)com> writes:
It seems that this is really up to the application. Both
server names
are authenticated under the same session. It seems an application
server may require them to be the same or allow them to be
different.
I would agree if the draft wouldn't prevent clients from
requesting a different server name at the application layer:
negotiated in the application protocol. If the server_name is
established in the TLS session handshake, the client SHOULD NOT
attempt to request a different server name at the
application layer.
At least that is how I read it.
[Joe] Good point, however I still think it is application protocol that
needs to enforce the matching if it cares. Perhaps we can add some text
that states
"Since it is possible for a client to present a different server_name in
the application protocol, application server implementators should take
this into account and take appropriate action to avoid introducing
security vulnerabilities if the names do not match. "
Peter's text also included the possibility of server name change during
a renegotiation handshake, do you think we should include this
consideration here as well?
/Simon
-----Original Message-----
From: tls-bounces(_at_)ietf(_dot_)org
[mailto:tls-bounces(_at_)ietf(_dot_)org]
On Behalf Of
Michael D'Errico
Sent: Tuesday, September 29, 2009 4:48 PM
To: martin(_dot_)rex(_at_)sap(_dot_)com
Cc: simon(_at_)josefsson(_dot_)org; ietf(_at_)ietf(_dot_)org;
tls(_at_)ietf(_dot_)org
Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis
(Transport
Layer
I do not see why you consider this a vulnerability in the
_server_!
Because a malicious client could theoretically
establish a secure
connection using one server domain and then ask for
pages from a
different domain. If the server does not check for
this, it could
potentially leak sensitive information.
You're barking up the wrong tree. If the client did not
use TLS, the
server wouldn't even know that.
You must be talking about a particular server
implementation that has
this shortcomings. There is nothing inherent in TLS that
prevents a
server from knowing when it is used. Your library and/ or use of
that library is the problem.
It is inappropriate to assume that virtual hosting provides
seperation
of content and draw a conclusion that, when accesses via
HTTPS, will
provide a secure seperation of content instead.
I'm not assuming anything; I have written a TLS library
and an HTTP
server that provides the separation of content that you deny is
possible.
If the lack of such a server-side check is a problem for
your server,
then your server problably has a severe design flaw in
its session
management.
I never said my server suffered from this problem....
And I'm curious: why do you call matching the commonName weak?
Because in the vast majority of situatins it is the last
step in a
long row of flawed assumptions.
OK, so you are complaining about the entirety of e-commerce on the
web. Do you have any proposed solutions to these problems?
Mike
Security is only as strong as its weakest link. The
authentication
process based on a DNSName involves a number of very weak
authentications.
DNS domain names are not very genuine, and it is very
non-obvious
which domain names are used by the business or peer someone
is looking
for and which are used by others (different businesses with
the same
name, cybersquatters or attackers). Most HTTPS-URLs
opened by Web
Browsers are served through plaintext HTTP pages.
Then most Browser PKIs come with a hundred or more trusted CAs
preconfigured, and browsers trust them equally. Whether or
how secure
the authentication is that the CA performs before issuing a
certificate is another flawed assumption that weakens the
rfc-2818 server endpoint authentication.
A final flaw that is still present in most browsers is
the lack of
memory. Not memorizing the certificate that a server
presented on the
last contact perpetuates the weakness of the original
authentication.
Personally, I think that deriving a server endpoint
identifier from a
network address is the most flawed assumption of all.
That is like asserting that if someone opens on a random
door on which
you knock, and shows you an ID card with the correct street
address --
then he must be a GOOD guy.
-Martin
_______________________________________________
TLS mailing list
TLS(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf