...@ietf.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
@sap.com; ietf@ietf.org; t...@ietf.org
Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis
(Transport Layer
Joseph Salowey (jsalowey) jsalo...@cisco.com writes:
It seems that this is really up to the application. Both
server names
are authenticated under the same session. It seems
Michael D'Errico wrote:
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
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
D'Errico; martin@sap.com; ietf@ietf.org; t...@ietf.org
Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis
(Transport Layer
Joseph Salowey (jsalowey) jsalo...@cisco.com writes:
It seems that this is really up to the application. Both
server names
are authenticated under the same
Simon Josefsson wrote:
One attack could works like this:
1) Client establish an client-authenticated HTTPS session with a TLS SNI
for blog.example.org and sends a HTTP GET with a Host: header for
internal-website.example.org.
2) The server TLS code authenticate and authorize the client
Martin Rex wrote:
Simon Josefsson wrote:
One attack could works like this:
1) Client establish an client-authenticated HTTPS session with a TLS SNI
for blog.example.org and sends a HTTP GET with a Host: header for
internal-website.example.org.
2) The server TLS code authenticate and authorize
] On
Behalf Of Michael D'Errico
Sent: Tuesday, September 29, 2009 4:48 PM
To: martin@sap.com
Cc: si...@josefsson.org; ietf@ietf.org; t...@ietf.org
Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis
(Transport Layer
I do not see why you consider this a vulnerability
] 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
Simon Josefsson wrote:
I am aware that the IETF-wide last call has ended, but Daniel Black
provided a suggestion (posted on the gnutls-devel list) for the
Security Considerations that I agree with and believe can be
important. Quoting him, slightly reworded:
also maybe 11.1. could say,
What about some text like
It is the responsibility of application to properly react on
the values for servername presented during session
initiation or session resumption and any related value(s)
presented during the application protocol
according to the needs of the application.
All values can
At Wed, 23 Sep 2009 15:04:00 -0400 (EDT),
Dean Anderson wrote:
Is that insecure?
If the client is authorized by certificate, then it seems that it has
that identity in addition to any application level identities.
The only insecurity is if the certifiate private key has been
12 matches
Mail list logo
