Discussion:
[squid-users] host_verify_strict and wildcard SNI
Steve Hill
2016-07-06 14:36:25 UTC
Permalink
I'm using a transparent proxy and SSL-peek and have hit a problem with
an iOS app which seems to be doing broken things with the SNI.

The app is making an HTTPS connection to a server and presenting an SNI
with a wildcard in it - i.e. "*.example.com". I'm not sure if this
behaviour is actually illegal, but it certainly doesn't seem to make a
lot of sense to me.

Squid then internally generates a "CONNECT *.example.com:443" request
based on the peeked SNI, which is picked up by hostHeaderIpVerify().
Since *.example.com isn't a valid DNS name, Squid rejects the connection
on the basis that *.example.com doesn't match the IP address that the
client is connecting to.

Unfortunately, I can't see any way of working around the problem -
"host_verify_strict" is disabled, but according to the docs,
"For now suspicious intercepted CONNECT requests are always responded to
with an HTTP 409 (Conflict) error page."

As I understand it, turning host_verify_strict on causes problems with
CDNs which use DNS tricks for load balancing, so I'm not sure I
understand the rationale behind preventing it from being turned off for
CONNECT requests?
--
- Steve Hill
Technical Director
Opendium Limited http://www.opendium.com

Direct contacts:
Instant messager: xmpp:***@opendium.com
Email: ***@opendium.com
Phone: sip:***@opendium.com

Sales / enquiries contacts:
Email: ***@opendium.com
Phone: +44-1792-824568 / sip:***@opendium.com

Support contacts:
Email: ***@opendium.com
Phone: +44-1792-825748 / sip:***@opendium.com
Yuri Voinov
2016-07-06 19:43:23 UTC
Permalink
Sounds familiar.

Do you experience occasional problems with CloudFlare sites?
Post by Steve Hill
I'm using a transparent proxy and SSL-peek and have hit a problem with
an iOS app which seems to be doing broken things with the SNI.
Post by Steve Hill
The app is making an HTTPS connection to a server and presenting an
SNI with a wildcard in it - i.e. "*.example.com". I'm not sure if this
behaviour is actually illegal, but it certainly doesn't seem to make a
lot of sense to me.
Post by Steve Hill
Squid then internally generates a "CONNECT *.example.com:443" request
based on the peeked SNI, which is picked up by hostHeaderIpVerify().
Since *.example.com isn't a valid DNS name, Squid rejects the connection
on the basis that *.example.com doesn't match the IP address that the
client is connecting to.
Post by Steve Hill
Unfortunately, I can't see any way of working around the problem -
"host_verify_strict" is disabled, but according to the docs,
Post by Steve Hill
"For now suspicious intercepted CONNECT requests are always responded
to with an HTTP 409 (Conflict) error page."
Post by Steve Hill
As I understand it, turning host_verify_strict on causes problems with
CDNs which use DNS tricks for load balancing, so I'm not sure I
understand the rationale behind preventing it from being turned off for
CONNECT requests?
Eliezer Croitoru
2016-07-06 19:54:10 UTC
Permalink
Hey Yuri,

These two subjects are not related directly to each other but they might have something in common.
Squid expects clients connections to meet the basic RFC6066 section 3:
https://tools.ietf.org/html/rfc6066#section-3

Which states that a host name should be there and the legal characters of a hostname from both rfc1035 and rc6066 are very speicifc.
If a specific software are trying to request a wrong sni name it's an issue in the client side request or software error handling and enforcement.
A http server would probably respond with a 4XX response code or the default certificate.
There are other options of course but the first thing to check is if the client is a real browser or some special creature that tries it's luck with a special form of ssl.
To my understanding host_verify_strict tries to enforce basic security levels while in a transparent proxy the rules will always change.

Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: ***@ngtech.co.il


-----Original Message-----
From: squid-users [mailto:squid-users-***@lists.squid-cache.org] On Behalf Of Yuri Voinov
Sent: Wednesday, July 6, 2016 10:43 PM
To: squid-***@lists.squid-cache.org
Subject: Re: [squid-users] host_verify_strict and wildcard SNI


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Sounds familiar.

Do you experience occasional problems with CloudFlare sites?
Post by Steve Hill
I'm using a transparent proxy and SSL-peek and have hit a problem with
an iOS app which seems to be doing broken things with the SNI.
Post by Steve Hill
The app is making an HTTPS connection to a server and presenting an
SNI with a wildcard in it - i.e. "*.example.com". I'm not sure if this
behaviour is actually illegal, but it certainly doesn't seem to make a
lot of sense to me.
Post by Steve Hill
Squid then internally generates a "CONNECT *.example.com:443" request
based on the peeked SNI, which is picked up by hostHeaderIpVerify().
Since *.example.com isn't a valid DNS name, Squid rejects the connection
on the basis that *.example.com doesn't match the IP address that the
client is connecting to.
Post by Steve Hill
Unfortunately, I can't see any way of working around the problem -
"host_verify_strict" is disabled, but according to the docs,
Post by Steve Hill
"For now suspicious intercepted CONNECT requests are always responded
to with an HTTP 409 (Conflict) error page."
Post by Steve Hill
As I understand it, turning host_verify_strict on causes problems with
CDNs which use DNS tricks for load balancing, so I'm not sure I
understand the rationale behind preventing it from being turned off for
CONNECT requests?
Yuri Voinov
2016-07-06 20:14:32 UTC
Permalink
I know. Just asked. Since I am familiar with the standards.
Post by Eliezer Croitoru
Hey Yuri,
These two subjects are not related directly to each other but they
might have something in common.
Post by Eliezer Croitoru
https://tools.ietf.org/html/rfc6066#section-3
Which states that a host name should be there and the legal characters
of a hostname from both rfc1035 and rc6066 are very speicifc.
Post by Eliezer Croitoru
If a specific software are trying to request a wrong sni name it's an
issue in the client side request or software error handling and enforcement.
Post by Eliezer Croitoru
A http server would probably respond with a 4XX response code or the default certificate.
There are other options of course but the first thing to check is if
the client is a real browser or some special creature that tries it's
luck with a special form of ssl.
Post by Eliezer Croitoru
To my understanding host_verify_strict tries to enforce basic security
levels while in a transparent proxy the rules will always change.
Post by Eliezer Croitoru
Eliezer
----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
-----Original Message-----
Sent: Wednesday, July 6, 2016 10:43 PM
Subject: Re: [squid-users] host_verify_strict and wildcard SNI
Sounds familiar.
Do you experience occasional problems with CloudFlare sites?
Post by Steve Hill
I'm using a transparent proxy and SSL-peek and have hit a problem with
an iOS app which seems to be doing broken things with the SNI.
Post by Steve Hill
The app is making an HTTPS connection to a server and presenting an
SNI with a wildcard in it - i.e. "*.example.com". I'm not sure if this
behaviour is actually illegal, but it certainly doesn't seem to make a
lot of sense to me.
Post by Steve Hill
Squid then internally generates a "CONNECT *.example.com:443" request
based on the peeked SNI, which is picked up by hostHeaderIpVerify().
Since *.example.com isn't a valid DNS name, Squid rejects the connection
on the basis that *.example.com doesn't match the IP address that the
client is connecting to.
Post by Steve Hill
Unfortunately, I can't see any way of working around the problem -
"host_verify_strict" is disabled, but according to the docs,
Post by Steve Hill
"For now suspicious intercepted CONNECT requests are always responded
to with an HTTP 409 (Conflict) error page."
Post by Steve Hill
As I understand it, turning host_verify_strict on causes problems with
CDNs which use DNS tricks for load balancing, so I'm not sure I
understand the rationale behind preventing it from being turned off for
CONNECT requests?
Eliezer Croitoru
2016-07-06 20:38:55 UTC
Permalink
Hey Yuri,

I am not the "standards" guy but I do know that if something can be encoded
it can be "decoded".
There are special cases which needs special "spice" which sometimes is not
present here or there on the shelves.
To my disappointment and happiness there are very good products out there
which are not squid with much better fines invested in them.
I can clearly say that the Squid-Cache project is not the most "advanced"
piece of software in the market and I know that it cannot compare to let say
even 500 coding programmers work.
I have seen couple products that are open source which tries to provide
functionality which is similar to squid only in the protocol level and a
simple proxy with great luck.
Some of them are not as great as they might seems but I think that a young
programmer with enough investment can learn the required subjects to
implement a solution.
However, here admins, users, programmers can ask questions as they please
and I encourage to ask.
I try to answer as much as I can and in many cases my knowledge might not
be enough but I am trying to answer what I can with hope that it will help.
And unlike MD Doctors SysAdmins do not need to swear on something like "do
not harm" and I think it's a good aspect on things.

I am still looking for clues about cloudflare since I have yet to see the
person who hold the keys for them.

Eliezer

----
Eliezer Croitoru <http://ngtech.co.il/lmgtfy/>
Linux System Administrator
Mobile: +972-5-28704261
Email: ***@ngtech.co.il


From: Yuri Voinov [mailto:***@gmail.com]
Sent: Wednesday, July 6, 2016 11:15 PM
To: Eliezer Croitoru; squid-***@lists.squid-cache.org
Subject: Re: [squid-users] host_verify_strict and wildcard SNI


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I know. Just asked. Since I am familiar with the standards.
Post by Eliezer Croitoru
Hey Yuri,
These two subjects are not related directly to each other but
they might have something in common.
Post by Eliezer Croitoru
Squid expects clients connections to meet the basic RFC6066
https://tools.ietf.org/html/rfc6066#section-3
<https://tools.ietf.org/html/rfc6066>
Post by Eliezer Croitoru
Which states that a host name should be there and the legal
characters of a hostname from both rfc1035 and rc6066 are very
speicifc.
Post by Eliezer Croitoru
If a specific software are trying to request a wrong sni name
it's an issue in the client side request or software error
handling and enforcement.
Post by Eliezer Croitoru
A http server would probably respond with a 4XX response code
or the default certificate.
Post by Eliezer Croitoru
There are other options of course but the first thing to
check is if the client is a real browser or some special creature
that tries it's luck with a special form of ssl.
Post by Eliezer Croitoru
To my understanding host_verify_strict tries to enforce basic
security levels while in a transparent proxy the rules will always
change.
Post by Eliezer Croitoru
Eliezer
----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
-----Original Message-----
From: squid-users
[mailto:squid-users-***@lists.squid-cache.org] On Behalf Of
Yuri Voinov
Post by Eliezer Croitoru
Sent: Wednesday, July 6, 2016 10:43 PM
Subject: Re: [squid-users] host_verify_strict and wildcard
SNI
Post by Eliezer Croitoru
Sounds familiar.
Do you experience occasional problems with CloudFlare sites?
Post by Steve Hill
I'm using a transparent proxy and SSL-peek and have hit
a problem with
Post by Eliezer Croitoru
an iOS app which seems to be doing broken things with the
SNI.
Post by Eliezer Croitoru
Post by Steve Hill
The app is making an HTTPS connection to a server and
presenting an
Post by Eliezer Croitoru
SNI with a wildcard in it - i.e. "*.example.com". I'm not
sure if this
Post by Eliezer Croitoru
behaviour is actually illegal, but it certainly doesn't seem
to make a
Post by Eliezer Croitoru
lot of sense to me.
Post by Steve Hill
Squid then internally generates a "CONNECT
*.example.com:443" request
Post by Eliezer Croitoru
based on the peeked SNI, which is picked up by
hostHeaderIpVerify().
Post by Eliezer Croitoru
Since *.example.com isn't a valid DNS name, Squid rejects the
connection
Post by Eliezer Croitoru
on the basis that *.example.com doesn't match the IP address
that the
Post by Eliezer Croitoru
client is connecting to.
Post by Steve Hill
Unfortunately, I can't see any way of working around the
problem -
Post by Eliezer Croitoru
"host_verify_strict" is disabled, but according to the docs,
Post by Steve Hill
"For now suspicious intercepted CONNECT requests are
always responded
Post by Eliezer Croitoru
to with an HTTP 409 (Conflict) error page."
Post by Steve Hill
As I understand it, turning host_verify_strict on causes
problems with
Post by Eliezer Croitoru
CDNs which use DNS tricks for load balancing, so I'm not sure
I
Post by Eliezer Croitoru
understand the rationale behind preventing it from being
turned off for
Post by Eliezer Croitoru
CONNECT requests?
Yuri Voinov
2016-07-06 20:48:57 UTC
Permalink
I am very seriously concerned about the issue CDN, because every day I
discover more and more problematic sites, namely in connection with the
CDN and HTTPS. For more than four Squid servers are experiencing these
problems in my network. And I still do not see any reason why any
solutions to these problems.

Moreover, the splice does not solve these problems.

Just skip the whole networks in the proxy bypass.

What is totally unacceptable. Traffic is money. And a lot of money.
Post by Eliezer Croitoru
Hey Yuri,
I am not the "standards" guy but I do know that if something can be encoded
it can be "decoded".
There are special cases which needs special "spice" which sometimes is not
present here or there on the shelves.
To my disappointment and happiness there are very good products out there
which are not squid with much better fines invested in them.
I can clearly say that the Squid-Cache project is not the most "advanced"
piece of software in the market and I know that it cannot compare to let say
even 500 coding programmers work.
I have seen couple products that are open source which tries to provide
functionality which is similar to squid only in the protocol level and a
simple proxy with great luck.
Some of them are not as great as they might seems but I think that a young
programmer with enough investment can learn the required subjects to
implement a solution.
However, here admins, users, programmers can ask questions as they please
and I encourage to ask.
I try to answer as much as I can and in many cases my knowledge might not
be enough but I am trying to answer what I can with hope that it will help.
And unlike MD Doctors SysAdmins do not need to swear on something like "do
not harm" and I think it's a good aspect on things.
I am still looking for clues about cloudflare since I have yet to see the
person who hold the keys for them.
Eliezer
----
Eliezer Croitoru <http://ngtech.co.il/lmgtfy/>
Linux System Administrator
Mobile: +972-5-28704261
Sent: Wednesday, July 6, 2016 11:15 PM
Subject: Re: [squid-users] host_verify_strict and wildcard SNI
I know. Just asked. Since I am familiar with the standards.
Post by Eliezer Croitoru
Hey Yuri,
These two subjects are not related directly to each other but
they might have something in common.
Post by Eliezer Croitoru
Squid expects clients connections to meet the basic RFC6066
https://tools.ietf.org/html/rfc6066#section-3
<https://tools.ietf.org/html/rfc6066>
Post by Eliezer Croitoru
Which states that a host name should be there and the legal
characters of a hostname from both rfc1035 and rc6066 are very
speicifc.
Post by Eliezer Croitoru
If a specific software are trying to request a wrong sni name
it's an issue in the client side request or software error
handling and enforcement.
Post by Eliezer Croitoru
A http server would probably respond with a 4XX response code
or the default certificate.
Post by Eliezer Croitoru
There are other options of course but the first thing to
check is if the client is a real browser or some special creature
that tries it's luck with a special form of ssl.
Post by Eliezer Croitoru
To my understanding host_verify_strict tries to enforce basic
security levels while in a transparent proxy the rules will always
change.
Post by Eliezer Croitoru
Eliezer
----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
-----Original Message-----
From: squid-users
Yuri Voinov
Post by Eliezer Croitoru
Sent: Wednesday, July 6, 2016 10:43 PM
Subject: Re: [squid-users] host_verify_strict and wildcard
SNI
Post by Eliezer Croitoru
Sounds familiar.
Do you experience occasional problems with CloudFlare sites?
Post by Steve Hill
I'm using a transparent proxy and SSL-peek and have hit
a problem with
Post by Eliezer Croitoru
an iOS app which seems to be doing broken things with the
SNI.
Post by Eliezer Croitoru
Post by Steve Hill
The app is making an HTTPS connection to a server and
presenting an
Post by Eliezer Croitoru
SNI with a wildcard in it - i.e. "*.example.com". I'm not
sure if this
Post by Eliezer Croitoru
behaviour is actually illegal, but it certainly doesn't seem
to make a
Post by Eliezer Croitoru
lot of sense to me.
Post by Steve Hill
Squid then internally generates a "CONNECT
*.example.com:443" request
Post by Eliezer Croitoru
based on the peeked SNI, which is picked up by
hostHeaderIpVerify().
Post by Eliezer Croitoru
Since *.example.com isn't a valid DNS name, Squid rejects the
connection
Post by Eliezer Croitoru
on the basis that *.example.com doesn't match the IP address
that the
Post by Eliezer Croitoru
client is connecting to.
Post by Steve Hill
Unfortunately, I can't see any way of working around the
problem -
Post by Eliezer Croitoru
"host_verify_strict" is disabled, but according to the docs,
Post by Steve Hill
"For now suspicious intercepted CONNECT requests are
always responded
Post by Eliezer Croitoru
to with an HTTP 409 (Conflict) error page."
Post by Steve Hill
As I understand it, turning host_verify_strict on causes
problems with
Post by Eliezer Croitoru
CDNs which use DNS tricks for load balancing, so I'm not sure
I
Post by Eliezer Croitoru
understand the rationale behind preventing it from being
turned off for
Post by Eliezer Croitoru
CONNECT requests?
Eliezer Croitoru
2016-07-06 21:53:49 UTC
Permalink
If the splice doesn’t solve the issue what would you expect squid to do?

Spilce equals routing


The other solution which ufdbguard implements is probing the destination hosts.

If you want a solution I can try to see if it is possible but I cannot guarantee that you or anyone will like it.



Eliezer



----

<http://ngtech.co.il/lmgtfy/> Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: ***@ngtech.co.il





From: Yuri Voinov [mailto:***@gmail.com]
Sent: Wednesday, July 6, 2016 11:49 PM
To: Eliezer Croitoru; squid-***@lists.squid-cache.org
Subject: Re: [squid-users] host_verify_strict and wildcard SNI




-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I am very seriously concerned about the issue CDN, because every day I discover more and more problematic sites, namely in connection with the CDN and HTTPS. For more than four Squid servers are experiencing these problems in my network. And I still do not see any reason why any solutions to these problems.

Moreover, the splice does not solve these problems.

Just skip the whole networks in the proxy bypass.

What is totally unacceptable. Traffic is money. And a lot of money.
Post by Eliezer Croitoru
Hey Yuri,
I am not the "standards" guy but I do know that if something
can be encoded
Post by Eliezer Croitoru
it can be "decoded".
There are special cases which needs special "spice" which
sometimes is not
Post by Eliezer Croitoru
present here or there on the shelves.
To my disappointment and happiness there are very good
products out there
Post by Eliezer Croitoru
which are not squid with much better fines invested in them.
I can clearly say that the Squid-Cache project is not the
most "advanced"
Post by Eliezer Croitoru
piece of software in the market and I know that it cannot
compare to let say
Post by Eliezer Croitoru
even 500 coding programmers work.
I have seen couple products that are open source which tries
to provide
Post by Eliezer Croitoru
functionality which is similar to squid only in the protocol
level and a
Post by Eliezer Croitoru
simple proxy with great luck.
Some of them are not as great as they might seems but I think
that a young
Post by Eliezer Croitoru
programmer with enough investment can learn the required
subjects to
Post by Eliezer Croitoru
implement a solution.
However, here admins, users, programmers can ask questions as
they please
Post by Eliezer Croitoru
and I encourage to ask.
I try to answer as much as I can and in many cases my
knowledge might not
Post by Eliezer Croitoru
be enough but I am trying to answer what I can with hope that
it will help.
Post by Eliezer Croitoru
And unlike MD Doctors SysAdmins do not need to swear on
something like "do
Post by Eliezer Croitoru
not harm" and I think it's a good aspect on things.
I am still looking for clues about cloudflare since I have
yet to see the
Post by Eliezer Croitoru
person who hold the keys for them.
Eliezer
----
Eliezer Croitoru <http://ngtech.co.il/lmgtfy/> <http://ngtech.co.il/lmgtfy/>
Linux System Administrator
Mobile: +972-5-28704261
Sent: Wednesday, July 6, 2016 11:15 PM
Subject: Re: [squid-users] host_verify_strict and wildcard
SNI
Post by Eliezer Croitoru
I know. Just asked. Since I am familiar with the standards.
Post by Eliezer Croitoru
Hey Yuri,
These two subjects are not related directly to
each other but
Post by Eliezer Croitoru
they might have something in common.
Post by Eliezer Croitoru
Squid expects clients connections to meet the
basic RFC6066
Post by Eliezer Croitoru
Post by Eliezer Croitoru
https://tools.ietf.org/html/rfc6066#section-3
<https://tools.ietf.org/html/rfc6066> <https://tools.ietf.org/html/rfc6066>
Post by Eliezer Croitoru
Which states that a host name should be there and
the legal
Post by Eliezer Croitoru
characters of a hostname from both rfc1035 and rc6066
are very
Post by Eliezer Croitoru
speicifc.
Post by Eliezer Croitoru
If a specific software are trying to request a
wrong sni name
Post by Eliezer Croitoru
it's an issue in the client side request or software
error
Post by Eliezer Croitoru
handling and enforcement.
Post by Eliezer Croitoru
A http server would probably respond with a 4XX
response code
Post by Eliezer Croitoru
or the default certificate.
Post by Eliezer Croitoru
There are other options of course but the first
thing to
Post by Eliezer Croitoru
check is if the client is a real browser or some
special creature
Post by Eliezer Croitoru
that tries it's luck with a special form of ssl.
Post by Eliezer Croitoru
To my understanding host_verify_strict tries to
enforce basic
Post by Eliezer Croitoru
security levels while in a transparent proxy the rules
will always
Post by Eliezer Croitoru
change.
Post by Eliezer Croitoru
Eliezer
----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
-----Original Message-----
From: squid-users
Behalf Of
Post by Eliezer Croitoru
Yuri Voinov
Post by Eliezer Croitoru
Sent: Wednesday, July 6, 2016 10:43 PM
Subject: Re: [squid-users] host_verify_strict and
wildcard
Post by Eliezer Croitoru
SNI
Post by Eliezer Croitoru
Sounds familiar.
Do you experience occasional problems with
CloudFlare sites?
Post by Eliezer Croitoru
Post by Eliezer Croitoru
Post by Steve Hill
I'm using a transparent proxy and SSL-peek
and have hit
Post by Eliezer Croitoru
a problem with
Post by Eliezer Croitoru
an iOS app which seems to be doing broken things
with the
Post by Eliezer Croitoru
SNI.
Post by Eliezer Croitoru
Post by Steve Hill
The app is making an HTTPS connection to a
server and
Post by Eliezer Croitoru
presenting an
Post by Eliezer Croitoru
SNI with a wildcard in it - i.e. "*.example.com".
I'm not
Post by Eliezer Croitoru
sure if this
Post by Eliezer Croitoru
behaviour is actually illegal, but it certainly
doesn't seem
Post by Eliezer Croitoru
to make a
Post by Eliezer Croitoru
lot of sense to me.
Post by Steve Hill
Squid then internally generates a "CONNECT
*.example.com:443" request
Post by Eliezer Croitoru
based on the peeked SNI, which is picked up by
hostHeaderIpVerify().
Post by Eliezer Croitoru
Since *.example.com isn't a valid DNS name, Squid
rejects the
Post by Eliezer Croitoru
connection
Post by Eliezer Croitoru
on the basis that *.example.com doesn't match the
IP address
Post by Eliezer Croitoru
that the
Post by Eliezer Croitoru
client is connecting to.
Post by Steve Hill
Unfortunately, I can't see any way of working
around the
Post by Eliezer Croitoru
problem -
Post by Eliezer Croitoru
"host_verify_strict" is disabled, but according to
the docs,
Post by Eliezer Croitoru
Post by Eliezer Croitoru
Post by Steve Hill
"For now suspicious intercepted CONNECT
requests are
Post by Eliezer Croitoru
always responded
Post by Eliezer Croitoru
to with an HTTP 409 (Conflict) error page."
Post by Steve Hill
As I understand it, turning
host_verify_strict on causes
Post by Eliezer Croitoru
problems with
Post by Eliezer Croitoru
CDNs which use DNS tricks for load balancing, so
I'm not sure
Post by Eliezer Croitoru
I
Post by Eliezer Croitoru
understand the rationale behind preventing it from
being
Post by Eliezer Croitoru
turned off for
Post by Eliezer Croitoru
CONNECT requests?
Steve Hill
2016-07-07 16:29:38 UTC
Permalink
Post by Eliezer Croitoru
There are other options of course but the first thing to check is if the client is a real browser or some special creature that tries it's luck with a special form of ssl.
In this case it isn't a real web browser - it's an iOS app, and the
vendor has stated that they have no intention of fixing it :(
--
- Steve Hill
Technical Director
Opendium Limited http://www.opendium.com

Direct contacts:
Instant messager: xmpp:***@opendium.com
Email: ***@opendium.com
Phone: sip:***@opendium.com

Sales / enquiries contacts:
Email: ***@opendium.com
Phone: +44-1792-824568 / sip:***@opendium.com

Support contacts:
Email: ***@opendium.com
Phone: +44-1792-825748 / sip:***@opendium.com
Marcus Kool
2016-07-06 23:01:58 UTC
Permalink
I'm using a transparent proxy and SSL-peek and have hit a problem with an iOS app which seems to be doing broken things with the SNI.
The app is making an HTTPS connection to a server and presenting an SNI with a wildcard in it - i.e. "*.example.com". I'm not sure if this behaviour is actually illegal, but it certainly doesn't seem
to make a lot of sense to me.
Squid then internally generates a "CONNECT *.example.com:443" request based on the peeked SNI, which is picked up by hostHeaderIpVerify(). Since *.example.com isn't a valid DNS name, Squid rejects the
connection on the basis that *.example.com doesn't match the IP address that the client is connecting to.
Unfortunately, I can't see any way of working around the problem - "host_verify_strict" is disabled, but according to the docs,
"For now suspicious intercepted CONNECT requests are always responded to with an HTTP 409 (Conflict) error page."
As I understand it, turning host_verify_strict on causes problems with CDNs which use DNS tricks for load balancing, so I'm not sure I understand the rationale behind preventing it from being turned
off for CONNECT requests?
An SNI with a wildcard indeed does not make sense.

Since Squid tries to mimic the behavior of the server and of the client,
it deserves a patch where instead of doing a DNS lookup and then doing a
connect (based on the result of the DNS lookup?),
Squid simply connects to the IP address that the client tries to connect to
and does the TLS handshake with the SNI (that does not make sense).
This way it mimics the client a bit better.

Marcus
Alex Rousskov
2016-07-07 01:07:17 UTC
Permalink
Post by Marcus Kool
Post by Steve Hill
I'm using a transparent proxy and SSL-peek and have hit a problem with
an iOS app which seems to be doing broken things with the SNI.
The app is making an HTTPS connection to a server and presenting an
SNI with a wildcard in it - i.e. "*.example.com". I'm not sure if
this behaviour is actually illegal, but it certainly doesn't seem
to make a lot of sense to me.
An SNI with a wildcard indeed does not make sense.
There are three rather different questions to consider here:

1. Is wildcard SNI "legal/valid"?
2. Can wildcard SNI "make sense" in some cases?
3. What should Squid do when receiving a wildcard SNI?


Q1. Is wildcard SNI "legal/valid"?

I do not know the answer to that question. The "*.example.com" name is
certainly legal in many DNS contexts. RFC 6066 requires HostName SNI to
be a "fully qualified domain name", but I failed to find a strict-enough
RFC definition of an FQDN that would either accept or reject wildcards
as FQDNs. I would not be surprised if FQDN syntax is not defined to the
level that would allow one to reject wildcards as FQDNs based on syntax
alone.


Q2. Can wildcard SNI "make sense" in some cases?

Yes, of course. The client essentially says "I am trying to connect to
_any_ example.com subdomain at this IP:port address. If you have any
service like that, please connect me". That would work fine in
deployment contexts where several servers with different names provide
essentially the same service and the central "routing point" would pick
the "best" service to use. I am not saying it is a good idea to use
wildcard SNIs, but I can see them "making sense" in some cases.


Q3. What should Squid do when receiving a wildcard SNI?

The first two questions are not really important and each may not even
have a single "correct" answer. I am sure protocol purists can argue
Post by Marcus Kool
Since Squid tries to mimic the behavior of the server and of the client,
it deserves a patch where instead of doing a DNS lookup and then doing a
connect (based on the result of the DNS lookup?),
Squid simply connects to the IP address that the client tries to connect to
and does the TLS handshake with the SNI (that does not make sense).
This way it mimics the client a bit better.
I believe that is what Squid does already but please correct me if I am
wrong.

When forming a fake CONNECT request, Squid uses SNI information because
that is what ACLs and adaptation services usually want to see. However,
I hope that intercepting Squid always connects to the intended
destination of the intercepted connection instead of trusting its own
fake CONNECT request.

Whether Squid should generate a fake CONNECT with a wildcard host name
is an interesting question:

1. A fake CONNECT targeting an wildcard name may break ACL-driven rules
and adaptation services (at least).

2. A fake CONNECT targeting an IP address instead of a wildcard name may
not give some ACL-driven rules and adaptation services enough
information to make the right decision.

3. A premature rejection of a connection with wildcard SNI does not
allow the admin to make the bump/splice/terminate decision.

#2 is probably the lesser of the three evils, but I wonder whether Squid
should also include the invalid host name as an X-SNI or similar HTTP
header in that CONNECT request, to give advanced ACLs and adaptation
services a better chance to work around known benign issues where the
admin knows the wildcard is not malicious (and to kill wildcard
transactions the admin knows to be malicious!).


A similar question can be asked about SNI names containing unusual
characters. At some point, it would be too dangerous to include SNI
information in the fake CONNECT request because it will interfere with
HTTP rules, but it is not clear where that point is exactly.


Cheers,

Alex.
Marcus Kool
2016-07-07 01:55:29 UTC
Permalink
Post by Alex Rousskov
Post by Marcus Kool
Post by Steve Hill
I'm using a transparent proxy and SSL-peek and have hit a problem with
an iOS app which seems to be doing broken things with the SNI.
The app is making an HTTPS connection to a server and presenting an
SNI with a wildcard in it - i.e. "*.example.com". I'm not sure if
this behaviour is actually illegal, but it certainly doesn't seem
to make a lot of sense to me.
[snip]
Post by Alex Rousskov
Q3. What should Squid do when receiving a wildcard SNI?
The first two questions are not really important and each may not even
have a single "correct" answer. I am sure protocol purists can argue
Post by Marcus Kool
Since Squid tries to mimic the behavior of the server and of the client,
it deserves a patch where instead of doing a DNS lookup and then doing a
connect (based on the result of the DNS lookup?),
Squid simply connects to the IP address that the client tries to connect to
and does the TLS handshake with the SNI (that does not make sense).
This way it mimics the client a bit better.
I believe that is what Squid does already but please correct me if I am
wrong.
Steve said that Squid rejects the connection because of a failed DNS lookup.
So what is Squid doing? Is it doing the following ?
- connect to the original IP
- use the presented SNI to the server
- do a DNS lookup and reject
Post by Alex Rousskov
When forming a fake CONNECT request, Squid uses SNI information because
that is what ACLs and adaptation services usually want to see. However,
I hope that intercepting Squid always connects to the intended
destination of the intercepted connection instead of trusting its own
fake CONNECT request.
It is interesting to know if an ICAP server or URL rewriter is called
and with which parameters when the ios app breaks.
Post by Alex Rousskov
Whether Squid should generate a fake CONNECT with a wildcard host name
1. A fake CONNECT targeting an wildcard name may break ACL-driven rules
and adaptation services (at least).
2. A fake CONNECT targeting an IP address instead of a wildcard name may
not give some ACL-driven rules and adaptation services enough
information to make the right decision.
3. A premature rejection of a connection with wildcard SNI does not
allow the admin to make the bump/splice/terminate decision.
#2 is probably the lesser of the three evils, but I wonder whether Squid
should also include the invalid host name as an X-SNI or similar HTTP
header in that CONNECT request, to give advanced ACLs and adaptation
services a better chance to work around known benign issues where the
admin knows the wildcard is not malicious (and to kill wildcard
transactions the admin knows to be malicious!).
I use url_rewrite_extras with "... sni=\"%ssl::>sni\" ..."
so the URL redirector receives both the original IP address and
the peeked SNI value to make its decisions.
I agree that an ICAP service needs X-SNI or perhaps X-Squid-SNI to
also get both the IP address and the SNI value.
Post by Alex Rousskov
A similar question can be asked about SNI names containing unusual
characters. At some point, it would be too dangerous to include SNI
information in the fake CONNECT request because it will interfere with
HTTP rules, but it is not clear where that point is exactly.
To support the weirdest apps Squid might have to simply copy all
unusual characters to present the same parameter values to the server.
But we do not want to break things... so which characters are
so unusual that Squid does not want to accept them?

Marcus
Post by Alex Rousskov
Cheers,
Alex.
Amos Jeffries
2016-07-07 10:15:16 UTC
Permalink
Post by Marcus Kool
Post by Alex Rousskov
Post by Marcus Kool
Post by Steve Hill
I'm using a transparent proxy and SSL-peek and have hit a problem with
an iOS app which seems to be doing broken things with the SNI.
The app is making an HTTPS connection to a server and presenting an
SNI with a wildcard in it - i.e. "*.example.com". I'm not sure if
this behaviour is actually illegal, but it certainly doesn't seem
to make a lot of sense to me.
[snip]
Post by Alex Rousskov
Q3. What should Squid do when receiving a wildcard SNI?
The first two questions are not really important and each may not even
have a single "correct" answer. I am sure protocol purists can argue
Post by Marcus Kool
Since Squid tries to mimic the behavior of the server and of the client,
it deserves a patch where instead of doing a DNS lookup and then doing a
connect (based on the result of the DNS lookup?),
Squid simply connects to the IP address that the client tries to connect to
and does the TLS handshake with the SNI (that does not make sense).
This way it mimics the client a bit better.
I believe that is what Squid does already but please correct me if I am
wrong.
Steve said that Squid rejects the connection because of a failed DNS lookup.
So what is Squid doing? Is it doing the following ?
- connect to the original IP
- use the presented SNI to the server
- do a DNS lookup and reject
No it is doing Host: header verification on the faked CONNECT request
which uses the SNI in the Host: header value. This is not strictly
required for CONNECT messages, but does potentially prevent Squid using
other IPs than the original one the client was contacting.
If the SNI is a valid domain name (ie resolves in DNS). Then Squid
should continue on past the check.
Post by Marcus Kool
Post by Alex Rousskov
When forming a fake CONNECT request, Squid uses SNI information because
that is what ACLs and adaptation services usually want to see. However,
I hope that intercepting Squid always connects to the intended
destination of the intercepted connection instead of trusting its own
fake CONNECT request.
It is interesting to know if an ICAP server or URL rewriter is called
and with which parameters when the ios app breaks.
Post by Alex Rousskov
Whether Squid should generate a fake CONNECT with a wildcard host name
1. A fake CONNECT targeting an wildcard name may break ACL-driven rules
and adaptation services (at least).
2. A fake CONNECT targeting an IP address instead of a wildcard name may
not give some ACL-driven rules and adaptation services enough
information to make the right decision.
3. A premature rejection of a connection with wildcard SNI does not
allow the admin to make the bump/splice/terminate decision.
#2 is probably the lesser of the three evils, but I wonder whether Squid
should also include the invalid host name as an X-SNI or similar HTTP
header in that CONNECT request, to give advanced ACLs and adaptation
services a better chance to work around known benign issues where the
admin knows the wildcard is not malicious (and to kill wildcard
transactions the admin knows to be malicious!).
I use url_rewrite_extras with "... sni=\"%ssl::>sni\" ..."
so the URL redirector receives both the original IP address and
the peeked SNI value to make its decisions.
I agree that an ICAP service needs X-SNI or perhaps X-Squid-SNI to
also get both the IP address and the SNI value.
That is a problem for the service. Squid can already send anything in:
<http://www.squid-cache.org/Doc/config/adaptation_meta/>.

Maybe you have mistaken it for the inability of most ICAP services to
send things back to Squid in the same way.
Post by Marcus Kool
Post by Alex Rousskov
A similar question can be asked about SNI names containing unusual
characters. At some point, it would be too dangerous to include SNI
information in the fake CONNECT request because it will interfere with
HTTP rules, but it is not clear where that point is exactly.
To support the weirdest apps Squid might have to simply copy all
unusual characters to present the same parameter values to the server.
It is being mapped into the HTTP equivalent value. Which are Host:
header and authority-URI. Only valid FQDN names can make it through the
mapping.
Post by Marcus Kool
But we do not want to break things... so which characters are
so unusual that Squid does not want to accept them?
In Steve's case the asterisk at the start of the domain name. The name
labels must each start with an alphabet character a-z or A-Z. That is a
fixed requirement. The other characters that follow are where things get
fuzzy depending on what RFCs you follow.

Amos
Marcus Kool
2016-07-07 11:30:28 UTC
Permalink
Post by Amos Jeffries
Post by Marcus Kool
Post by Alex Rousskov
Post by Marcus Kool
Post by Steve Hill
I'm using a transparent proxy and SSL-peek and have hit a problem with
an iOS app which seems to be doing broken things with the SNI.
The app is making an HTTPS connection to a server and presenting an
SNI with a wildcard in it - i.e. "*.example.com". I'm not sure if
this behaviour is actually illegal, but it certainly doesn't seem
to make a lot of sense to me.
[snip]
Post by Alex Rousskov
Q3. What should Squid do when receiving a wildcard SNI?
The first two questions are not really important and each may not even
have a single "correct" answer. I am sure protocol purists can argue
Post by Marcus Kool
Since Squid tries to mimic the behavior of the server and of the client,
it deserves a patch where instead of doing a DNS lookup and then doing a
connect (based on the result of the DNS lookup?),
Squid simply connects to the IP address that the client tries to connect to
and does the TLS handshake with the SNI (that does not make sense).
This way it mimics the client a bit better.
I believe that is what Squid does already but please correct me if I am
wrong.
Steve said that Squid rejects the connection because of a failed DNS lookup.
So what is Squid doing? Is it doing the following ?
- connect to the original IP
- use the presented SNI to the server
- do a DNS lookup and reject
No it is doing Host: header verification on the faked CONNECT request
which uses the SNI in the Host: header value. This is not strictly
required for CONNECT messages, but does potentially prevent Squid using
other IPs than the original one the client was contacting.
Squid _has_ the original IP so why would Squid potentially connect to an
other IP ?
Post by Amos Jeffries
If the SNI is a valid domain name (ie resolves in DNS). Then Squid
should continue on past the check.
Does Squid do a DNS lookup or only check the value for "valid" characters?
Post by Amos Jeffries
Post by Marcus Kool
Post by Alex Rousskov
When forming a fake CONNECT request, Squid uses SNI information because
that is what ACLs and adaptation services usually want to see. However,
I hope that intercepting Squid always connects to the intended
destination of the intercepted connection instead of trusting its own
fake CONNECT request.
It is interesting to know if an ICAP server or URL rewriter is called
and with which parameters when the ios app breaks.
Post by Alex Rousskov
Whether Squid should generate a fake CONNECT with a wildcard host name
1. A fake CONNECT targeting an wildcard name may break ACL-driven rules
and adaptation services (at least).
2. A fake CONNECT targeting an IP address instead of a wildcard name may
not give some ACL-driven rules and adaptation services enough
information to make the right decision.
3. A premature rejection of a connection with wildcard SNI does not
allow the admin to make the bump/splice/terminate decision.
#2 is probably the lesser of the three evils, but I wonder whether Squid
should also include the invalid host name as an X-SNI or similar HTTP
header in that CONNECT request, to give advanced ACLs and adaptation
services a better chance to work around known benign issues where the
admin knows the wildcard is not malicious (and to kill wildcard
transactions the admin knows to be malicious!).
I use url_rewrite_extras with "... sni=\"%ssl::>sni\" ..."
so the URL redirector receives both the original IP address and
the peeked SNI value to make its decisions.
I agree that an ICAP service needs X-SNI or perhaps X-Squid-SNI to
also get both the IP address and the SNI value.
<http://www.squid-cache.org/Doc/config/adaptation_meta/>.
Which problem are you referring to?
Post by Amos Jeffries
Maybe you have mistaken it for the inability of most ICAP services to
send things back to Squid in the same way.
The ICAP server needs both the IP and the SNI which Squid can be configured
to do. What do you suggest that an ICAP server needs to send back to Squid?
Post by Amos Jeffries
Post by Marcus Kool
Post by Alex Rousskov
A similar question can be asked about SNI names containing unusual
characters. At some point, it would be too dangerous to include SNI
information in the fake CONNECT request because it will interfere with
HTTP rules, but it is not clear where that point is exactly.
To support the weirdest apps Squid might have to simply copy all
unusual characters to present the same parameter values to the server.
header and authority-URI. Only valid FQDN names can make it through the
mapping.
Here things get complicated.
It is correct that Squid enforces apps to follow standards or
should Squid try to proxy connections for apps when it can?

Marcus
Post by Amos Jeffries
Post by Marcus Kool
But we do not want to break things... so which characters are
so unusual that Squid does not want to accept them?
In Steve's case the asterisk at the start of the domain name. The name
labels must each start with an alphabet character a-z or A-Z. That is a
fixed requirement. The other characters that follow are where things get
fuzzy depending on what RFCs you follow.
Amos
Amos Jeffries
2016-07-07 12:23:30 UTC
Permalink
Post by Marcus Kool
Post by Amos Jeffries
Post by Marcus Kool
Post by Alex Rousskov
Post by Marcus Kool
Post by Steve Hill
I'm using a transparent proxy and SSL-peek and have hit a problem with
an iOS app which seems to be doing broken things with the SNI.
The app is making an HTTPS connection to a server and presenting an
SNI with a wildcard in it - i.e. "*.example.com". I'm not sure if
this behaviour is actually illegal, but it certainly doesn't seem
to make a lot of sense to me.
[snip]
Post by Alex Rousskov
Q3. What should Squid do when receiving a wildcard SNI?
The first two questions are not really important and each may not even
have a single "correct" answer. I am sure protocol purists can argue
Post by Marcus Kool
Since Squid tries to mimic the behavior of the server and of the client,
it deserves a patch where instead of doing a DNS lookup and then doing a
connect (based on the result of the DNS lookup?),
Squid simply connects to the IP address that the client tries to connect to
and does the TLS handshake with the SNI (that does not make sense).
This way it mimics the client a bit better.
I believe that is what Squid does already but please correct me if I am
wrong.
Steve said that Squid rejects the connection because of a failed DNS lookup.
So what is Squid doing? Is it doing the following ?
- connect to the original IP
- use the presented SNI to the server
- do a DNS lookup and reject
No it is doing Host: header verification on the faked CONNECT request
which uses the SNI in the Host: header value. This is not strictly
required for CONNECT messages, but does potentially prevent Squid using
other IPs than the original one the client was contacting.
Squid _has_ the original IP so why would Squid potentially connect to an
other IP ?
Because the inbound and outbound connections are not related. The
outbound is normally done to any of the IPs that the request message
domain/Host header resolve to. It takes special circumstances (such as
failing the Host verification) to tie them together.
Post by Marcus Kool
Post by Amos Jeffries
If the SNI is a valid domain name (ie resolves in DNS). Then Squid
should continue on past the check.
Does Squid do a DNS lookup or only check the value for "valid" characters?
DNS lookup.
Post by Marcus Kool
Post by Amos Jeffries
Post by Marcus Kool
Post by Alex Rousskov
When forming a fake CONNECT request, Squid uses SNI information because
that is what ACLs and adaptation services usually want to see. However,
I hope that intercepting Squid always connects to the intended
destination of the intercepted connection instead of trusting its own
fake CONNECT request.
It is interesting to know if an ICAP server or URL rewriter is called
and with which parameters when the ios app breaks.
Post by Alex Rousskov
Whether Squid should generate a fake CONNECT with a wildcard host name
1. A fake CONNECT targeting an wildcard name may break ACL-driven rules
and adaptation services (at least).
2. A fake CONNECT targeting an IP address instead of a wildcard name may
not give some ACL-driven rules and adaptation services enough
information to make the right decision.
3. A premature rejection of a connection with wildcard SNI does not
allow the admin to make the bump/splice/terminate decision.
#2 is probably the lesser of the three evils, but I wonder whether Squid
should also include the invalid host name as an X-SNI or similar HTTP
header in that CONNECT request, to give advanced ACLs and adaptation
services a better chance to work around known benign issues where the
admin knows the wildcard is not malicious (and to kill wildcard
transactions the admin knows to be malicious!).
I use url_rewrite_extras with "... sni=\"%ssl::>sni\" ..."
so the URL redirector receives both the original IP address and
the peeked SNI value to make its decisions.
I agree that an ICAP service needs X-SNI or perhaps X-Squid-SNI to
also get both the IP address and the SNI value.
<http://www.squid-cache.org/Doc/config/adaptation_meta/>.
Which problem are you referring to?
I mean it as: IF it is a problem, then its a problem for the service
side of things since Squid can send the data fine.
Post by Marcus Kool
Post by Amos Jeffries
Maybe you have mistaken it for the inability of most ICAP services to
send things back to Squid in the same way.
The ICAP server needs both the IP and the SNI which Squid can be configured
to do. What do you suggest that an ICAP server needs to send back to Squid?
Sorry I misread your earlier post as implying Squid needs to be extended
to send those details.
Post by Marcus Kool
Post by Amos Jeffries
Post by Marcus Kool
Post by Alex Rousskov
A similar question can be asked about SNI names containing unusual
characters. At some point, it would be too dangerous to include SNI
information in the fake CONNECT request because it will interfere with
HTTP rules, but it is not clear where that point is exactly.
To support the weirdest apps Squid might have to simply copy all
unusual characters to present the same parameter values to the server.
header and authority-URI. Only valid FQDN names can make it through the
mapping.
Here things get complicated.
It is correct that Squid enforces apps to follow standards or
should Squid try to proxy connections for apps when it can?
Squid isn't enforcing standards here. As Steve original messge says it:
"generates a "CONNECT *.example.com:443" request based on the peeked SNI"
- which is arguably invalid HTTP syntax, but oh well.

It then is unable to do a DNS lookup for *.example.com to find out what
its IPs are and does the error handling action for a failure to verify
on a CONNECT message.

Amos
Marcus Kool
2016-07-07 13:08:30 UTC
Permalink
Post by Amos Jeffries
Post by Marcus Kool
Post by Amos Jeffries
Post by Marcus Kool
Post by Alex Rousskov
Post by Marcus Kool
Post by Steve Hill
I'm using a transparent proxy and SSL-peek and have hit a problem with
an iOS app which seems to be doing broken things with the SNI.
The app is making an HTTPS connection to a server and presenting an
SNI with a wildcard in it - i.e. "*.example.com". I'm not sure if
this behaviour is actually illegal, but it certainly doesn't seem
to make a lot of sense to me.
[snip]
Post by Alex Rousskov
Q3. What should Squid do when receiving a wildcard SNI?
The first two questions are not really important and each may not even
have a single "correct" answer. I am sure protocol purists can argue
Post by Marcus Kool
Since Squid tries to mimic the behavior of the server and of the client,
it deserves a patch where instead of doing a DNS lookup and then doing a
connect (based on the result of the DNS lookup?),
Squid simply connects to the IP address that the client tries to connect to
and does the TLS handshake with the SNI (that does not make sense).
This way it mimics the client a bit better.
I believe that is what Squid does already but please correct me if I am
wrong.
Steve said that Squid rejects the connection because of a failed DNS lookup.
So what is Squid doing? Is it doing the following ?
- connect to the original IP
- use the presented SNI to the server
- do a DNS lookup and reject
No it is doing Host: header verification on the faked CONNECT request
which uses the SNI in the Host: header value. This is not strictly
required for CONNECT messages, but does potentially prevent Squid using
other IPs than the original one the client was contacting.
Squid _has_ the original IP so why would Squid potentially connect to an
other IP ?
Because the inbound and outbound connections are not related. The
outbound is normally done to any of the IPs that the request message
domain/Host header resolve to. It takes special circumstances (such as
failing the Host verification) to tie them together.
Oops. An application wants to connect to A.B.C.D has an SNI for foo.example.com
which resolves to A.B.C.D and A.B.C.E and Squid may connect the stream
to A.B.C.E... It is easy to imagine that some applications break with this behavior.
Post by Amos Jeffries
Post by Marcus Kool
Post by Amos Jeffries
If the SNI is a valid domain name (ie resolves in DNS). Then Squid
should continue on past the check.
Does Squid do a DNS lookup or only check the value for "valid" characters?
DNS lookup.
[snip]
Post by Amos Jeffries
Post by Marcus Kool
Post by Amos Jeffries
Post by Marcus Kool
Post by Alex Rousskov
A similar question can be asked about SNI names containing unusual
characters. At some point, it would be too dangerous to include SNI
information in the fake CONNECT request because it will interfere with
HTTP rules, but it is not clear where that point is exactly.
To support the weirdest apps Squid might have to simply copy all
unusual characters to present the same parameter values to the server.
header and authority-URI. Only valid FQDN names can make it through the
mapping.
Here things get complicated.
It is correct that Squid enforces apps to follow standards or
should Squid try to proxy connections for apps when it can?
"generates a "CONNECT *.example.com:443" request based on the peeked SNI"
- which is arguably invalid HTTP syntax, but oh well.
It then is unable to do a DNS lookup for *.example.com to find out what
its IPs are and does the error handling action for a failure to verify
on a CONNECT message.
yes, the fake CONNECT is dealt with like a regular CONNECT including
DNS lookup. I fear for other apps (besides the one ios app that Steve
refers to) to break because Squid may connect to a different IP than
the client/app is requesting.
If Squid uses the original IP to connect without doing a DNS lookup,
Steve's app will work and potential issues with other apps are
prevented.

Marcus
Post by Amos Jeffries
Amos
Yuri
2016-07-07 13:49:17 UTC
Permalink
Post by Marcus Kool
Post by Amos Jeffries
Post by Marcus Kool
Post by Amos Jeffries
Post by Marcus Kool
Post by Alex Rousskov
Post by Marcus Kool
Post by Steve Hill
I'm using a transparent proxy and SSL-peek and have hit a problem with
an iOS app which seems to be doing broken things with the SNI.
The app is making an HTTPS connection to a server and
presenting an
SNI with a wildcard in it - i.e. "*.example.com". I'm not sure if
this behaviour is actually illegal, but it certainly doesn't seem
to make a lot of sense to me.
[snip]
Post by Alex Rousskov
Q3. What should Squid do when receiving a wildcard SNI?
The first two questions are not really important and each may not even
have a single "correct" answer. I am sure protocol purists can argue
Post by Marcus Kool
Since Squid tries to mimic the behavior of the server and of the client,
it deserves a patch where instead of doing a DNS lookup and then doing a
connect (based on the result of the DNS lookup?),
Squid simply connects to the IP address that the client tries to connect to
and does the TLS handshake with the SNI (that does not make sense).
This way it mimics the client a bit better.
I believe that is what Squid does already but please correct me if I am
wrong.
Steve said that Squid rejects the connection because of a failed DNS lookup.
So what is Squid doing? Is it doing the following ?
- connect to the original IP
- use the presented SNI to the server
- do a DNS lookup and reject
No it is doing Host: header verification on the faked CONNECT request
which uses the SNI in the Host: header value. This is not strictly
required for CONNECT messages, but does potentially prevent Squid using
other IPs than the original one the client was contacting.
Squid _has_ the original IP so why would Squid potentially connect to an
other IP ?
Because the inbound and outbound connections are not related. The
outbound is normally done to any of the IPs that the request message
domain/Host header resolve to. It takes special circumstances (such as
failing the Host verification) to tie them together.
Oops. An application wants to connect to A.B.C.D has an SNI for foo.example.com
which resolves to A.B.C.D and A.B.C.E and Squid may connect the stream
to A.B.C.E... It is easy to imagine that some applications break with this behavior.
Post by Amos Jeffries
Post by Marcus Kool
Post by Amos Jeffries
If the SNI is a valid domain name (ie resolves in DNS). Then Squid
should continue on past the check.
Does Squid do a DNS lookup or only check the value for "valid" characters?
DNS lookup.
[snip]
Post by Amos Jeffries
Post by Marcus Kool
Post by Amos Jeffries
Post by Marcus Kool
Post by Alex Rousskov
A similar question can be asked about SNI names containing unusual
characters. At some point, it would be too dangerous to include SNI
information in the fake CONNECT request because it will interfere with
HTTP rules, but it is not clear where that point is exactly.
To support the weirdest apps Squid might have to simply copy all
unusual characters to present the same parameter values to the server.
header and authority-URI. Only valid FQDN names can make it through the
mapping.
Here things get complicated.
It is correct that Squid enforces apps to follow standards or
should Squid try to proxy connections for apps when it can?
"generates a "CONNECT *.example.com:443" request based on the peeked SNI"
- which is arguably invalid HTTP syntax, but oh well.
It then is unable to do a DNS lookup for *.example.com to find out what
its IPs are and does the error handling action for a failure to verify
on a CONNECT message.
yes, the fake CONNECT is dealt with like a regular CONNECT including
DNS lookup. I fear for other apps (besides the one ios app that Steve
refers to) to break because Squid may connect to a different IP than
the client/app is requesting.
If Squid uses the original IP to connect without doing a DNS lookup,
Steve's app will work and potential issues with other apps are
prevented.
Interestingly, Marcus. Does this mean that the CDN may be at different
points in time different IP connection and it makes it impossible for
client connections through Squid?
Post by Marcus Kool
Marcus
Post by Amos Jeffries
Amos
_______________________________________________
squid-users mailing list
http://lists.squid-cache.org/listinfo/squid-users
Marcus Kool
2016-07-07 13:59:47 UTC
Permalink
Post by Marcus Kool
Post by Amos Jeffries
Post by Marcus Kool
Post by Amos Jeffries
Post by Marcus Kool
Post by Alex Rousskov
A similar question can be asked about SNI names containing unusual
characters. At some point, it would be too dangerous to include SNI
information in the fake CONNECT request because it will interfere with
HTTP rules, but it is not clear where that point is exactly.
To support the weirdest apps Squid might have to simply copy all
unusual characters to present the same parameter values to the server.
header and authority-URI. Only valid FQDN names can make it through the
mapping.
Here things get complicated.
It is correct that Squid enforces apps to follow standards or
should Squid try to proxy connections for apps when it can?
"generates a "CONNECT *.example.com:443" request based on the peeked SNI"
- which is arguably invalid HTTP syntax, but oh well.
It then is unable to do a DNS lookup for *.example.com to find out what
its IPs are and does the error handling action for a failure to verify
on a CONNECT message.
yes, the fake CONNECT is dealt with like a regular CONNECT including
DNS lookup. I fear for other apps (besides the one ios app that Steve
refers to) to break because Squid may connect to a different IP than
the client/app is requesting.
If Squid uses the original IP to connect without doing a DNS lookup,
Steve's app will work and potential issues with other apps are
prevented.
Interestingly, Marcus. Does this mean that the CDN may be at different points in time different IP connection and it makes it impossible for client connections through Squid?
It all depends on the app/client: if it uses a servername/SNI that
resolves to multiple IP addresses but needs to connect to the one
that it specifically wants to CONNECT to, the app can fail since
Squid might choose an other IP address to connect to.

Or, apps might become slow since it might be faster when it reconnects
to the same server that it connected to before.
I think it is best to prevent issues and that Squid should connect
to the IP that the client is trying to connect to.

Marcus
Yuri Voinov
2016-07-07 14:49:23 UTC
Permalink
Post by Marcus Kool
Post by Yuri
Post by Marcus Kool
Post by Amos Jeffries
Post by Marcus Kool
Post by Amos Jeffries
Post by Marcus Kool
Post by Alex Rousskov
A similar question can be asked about SNI names containing unusual
characters. At some point, it would be too dangerous to include SNI
information in the fake CONNECT request because it will
interfere with
Post by Marcus Kool
Post by Yuri
Post by Marcus Kool
Post by Amos Jeffries
Post by Marcus Kool
Post by Amos Jeffries
Post by Marcus Kool
Post by Alex Rousskov
HTTP rules, but it is not clear where that point is exactly.
To support the weirdest apps Squid might have to simply copy all
unusual characters to present the same parameter values to the server.
header and authority-URI. Only valid FQDN names can make it through the
mapping.
Here things get complicated.
It is correct that Squid enforces apps to follow standards or
should Squid try to proxy connections for apps when it can?
"generates a "CONNECT *.example.com:443" request based on the peeked SNI"
- which is arguably invalid HTTP syntax, but oh well.
It then is unable to do a DNS lookup for *.example.com to find out what
its IPs are and does the error handling action for a failure to verify
on a CONNECT message.
yes, the fake CONNECT is dealt with like a regular CONNECT including
DNS lookup. I fear for other apps (besides the one ios app that Steve
refers to) to break because Squid may connect to a different IP than
the client/app is requesting.
If Squid uses the original IP to connect without doing a DNS lookup,
Steve's app will work and potential issues with other apps are
prevented.
Interestingly, Marcus. Does this mean that the CDN may be at
different points in time different IP connection and it makes it
impossible for client connections through Squid?
Post by Marcus Kool
It all depends on the app/client: if it uses a servername/SNI that
resolves to multiple IP addresses but needs to connect to the one
that it specifically wants to CONNECT to, the app can fail since
Squid might choose an other IP address to connect to.
Or, apps might become slow since it might be faster when it reconnects
to the same server that it connected to before.
I think it is best to prevent issues and that Squid should connect
to the IP that the client is trying to connect to.
I suggests, devs will say this is not secure. Client can be compromised
etc.etc.etc. :)
Post by Marcus Kool
Marcus
_______________________________________________
squid-users mailing list
http://lists.squid-cache.org/listinfo/squid-users
Alex Rousskov
2016-07-07 16:50:52 UTC
Permalink
Post by Amos Jeffries
Post by Marcus Kool
Post by Alex Rousskov
Q3. What should Squid do when receiving a wildcard SNI?
Squid _has_ the original IP so why would Squid potentially connect to an
other IP ?
Because the inbound and outbound connections are not related.
For intercepted connections they should be IMHO. By default, we should
[if allowed by all the internal checks] connect to the exact IP the
client was connecting to when we intercepted (cache peering, cache hits,
and similar special cases aside, of course).

Amos, are you sure we not doing that already for intercepted
connections? If we are not, I think this is a missing feature essential
for many (most?) deployments! I certainly understand that some admins
will need to "reroute" some intercepted requests, but rerouting ought to
be an exception, not the norm. Do you agree?

Please note that going to where the client went does not have to weaken
any internal checks.
Post by Amos Jeffries
The
outbound is normally done to any of the IPs that the request message
domain/Host header resolve to.
For intercepted SSL connections, there is no HTTP request message with
that information so it is especially pressing to connect to where the
client was going.

Perhaps we screwed it up by replacing the IP address with SNI in the
fake CONNECT target at some point? If that is what changed Squid
behavior, then we should fix the code so that Squid connects to the
intended destination IP regardless of the fake CONNECT target. One way
to do that would be to provide that intended IP address in the fake
CONNECT request itself, via X-Going-To or similar -- doing so would
allow adaptation services to adjust Squid behavior as needed.

[Wildcard] SNI validation is a separate problem that also needs a
solution. The feature/fix discussed above is not sufficient alone.


Thank you,

Alex.
Amos Jeffries
2016-07-07 19:53:32 UTC
Permalink
Post by Alex Rousskov
Post by Amos Jeffries
Post by Marcus Kool
Post by Alex Rousskov
Q3. What should Squid do when receiving a wildcard SNI?
Squid _has_ the original IP so why would Squid potentially connect to an
other IP ?
Because the inbound and outbound connections are not related.
For intercepted connections they should be IMHO. By default, we should
[if allowed by all the internal checks] connect to the exact IP the
client was connecting to when we intercepted (cache peering, cache hits,
and similar special cases aside, of course).
Amos, are you sure we not doing that already for intercepted
connections? If we are not, I think this is a missing feature essential
for many (most?) deployments! I certainly understand that some admins
will need to "reroute" some intercepted requests, but rerouting ought to
be an exception, not the norm. Do you agree?
Yes we are using the client ORIGINAL_DST as most preferred outgoing route.

However, when the admin configures "client_dst_passthru off" to force
the DNS results to be used, or configures cache_peer to be used instead
we obey those instructions instead. Also if the most preferred route is
down the alternatives can happen.
Post by Alex Rousskov
Please note that going to where the client went does not have to weaken
any internal checks.
Post by Amos Jeffries
The
outbound is normally done to any of the IPs that the request message
domain/Host header resolve to.
For intercepted SSL connections, there is no HTTP request message with
that information so it is especially pressing to connect to where the
client was going.
Perhaps we screwed it up by replacing the IP address with SNI in the
fake CONNECT target at some point? If that is what changed Squid
behavior, then we should fix the code so that Squid connects to the
intended destination IP regardless of the fake CONNECT target. One way
to do that would be to provide that intended IP address in the fake
CONNECT request itself, via X-Going-To or similar -- doing so would
allow adaptation services to adjust Squid behavior as needed.
I think the first CONNECT message which uses raw-IP should end with
setting up a (TCP only at this point) server connection of type PINNED.
Then the TLS bumping and second CONNECT message with SNI details should
use that connection for all the followup activity.
That would resolve other problems we are seeing with server connection
closure races as well.
Post by Alex Rousskov
[Wildcard] SNI validation is a separate problem that also needs a
solution. The feature/fix discussed above is not sufficient alone.
Nod.

Amos
Alex Rousskov
2016-07-07 23:41:09 UTC
Permalink
Post by Amos Jeffries
Post by Alex Rousskov
Post by Amos Jeffries
Post by Marcus Kool
Post by Alex Rousskov
Q3. What should Squid do when receiving a wildcard SNI?
Squid _has_ the original IP so why would Squid potentially connect to an
other IP ?
Because the inbound and outbound connections are not related.
For intercepted connections they should be IMHO. By default, we should
[if allowed by all the internal checks] connect to the exact IP the
client was connecting to when we intercepted (cache peering, cache hits,
and similar special cases aside, of course).
Amos, are you sure we not doing that already for intercepted
connections? If we are not, I think this is a missing feature essential
for many (most?) deployments! I certainly understand that some admins
will need to "reroute" some intercepted requests, but rerouting ought to
be an exception, not the norm. Do you agree?
Yes we are using the client ORIGINAL_DST as most preferred outgoing route.
Whew!
Post by Amos Jeffries
However, when the admin configures "client_dst_passthru off" to force
the DNS results to be used, or configures cache_peer to be used instead
we obey those instructions instead.
Sounds good.
Post by Amos Jeffries
Also if the most preferred route is
down the alternatives can happen.
That silent and poorly (or un)documented violation of the
"client_dst_passthru on" setting feels like a Squid bug to me, but this
is not my area of expertise.
Post by Amos Jeffries
Post by Alex Rousskov
Perhaps we screwed it up by replacing the IP address with SNI in the
fake CONNECT target at some point? If that is what changed Squid
behavior, then we should fix the code so that Squid connects to the
intended destination IP regardless of the fake CONNECT target. One way
to do that would be to provide that intended IP address in the fake
CONNECT request itself, via X-Going-To or similar -- doing so would
allow adaptation services to adjust Squid behavior as needed.
I think the first CONNECT message which uses raw-IP should end with
setting up a (TCP only at this point) server connection of type PINNED.
Then the TLS bumping and second CONNECT message with SNI details should
use that connection for all the followup activity.
I like that suggestion! However, if we do honor "client_dst_passthru on"
for bumped traffic already, then this [far from trivial] "TCP CONNECT"
implementation can wait.


Thank you,

Alex.
Steve Hill
2016-07-11 09:28:58 UTC
Permalink
Post by Marcus Kool
Here things get complicated.
It is correct that Squid enforces apps to follow standards or
should Squid try to proxy connections for apps when it can?
I would say no: where it is possible for Squid to allow an app to work,
even where it isn't following standards (without compromising security /
other software / etc.) then Squid needs to try to make the app work.

Unfortunately, end users do not understand the complexities, and if an
app works on their home internet connection and doesn't work through
their school / office connection (which is router through Squid) then as
far as they are concerned the school / office connection is "broken",
even if the problem is actually a broken app.

This is made worse by (1) the perception that big businesses such as
Microsoft / Apple / Google can never be wrong (even though this is not
born our by experience of their software), and (2) the fact that app
developers rarely seem at all interested in acknowledging/fixing such
bugs (in my experience).

So in the end you have a choice: live with people accusing Squid of
being "broken" and refuse to allow applications that will never be fixed
to work, or work around the broken apps within Squid and therefore get
them working without the cooperation of the app developers.
--
- Steve Hill
Technical Director
Opendium Limited http://www.opendium.com

Direct contacts:
Instant messager: xmpp:***@opendium.com
Email: ***@opendium.com
Phone: sip:***@opendium.com

Sales / enquiries contacts:
Email: ***@opendium.com
Phone: +44-1792-824568 / sip:***@opendium.com

Support contacts:
Email: ***@opendium.com
Phone: +44-1792-825748 / sip:***@opendium.com
Eliezer Croitoru
2016-07-07 07:37:06 UTC
Permalink
Couple thoughts Alex,

Currently the basic splice rules are being used with regex which means that they can work with wildcard.
And I can understand the argument of a client wanting some wildcard domain but I do not know about an application that actually
tries to uses such logic.

There are cases which the RFC do leave the open minds to get wild and I am not saying if these are right or wrong but,
they do states it's a hostname and not a certificate common name or some v3 component.

Practically some client can try to contact some arbitrary website and there are couple aspects to it.
If a user tries to connect to a site using a company proxy, then what companies will want to allow?
Would large companies allow such a connection to be spliced, or maybe they will want to inspect this connection deeper?
What about ISP's, these mostly care about cache and not about ACL's, while there are many who uses squid for content filtering.

From where anyone understands, a wildcard should never be required to be tested against any DNS server in the current state of the internet since these do have a strict policy to honor only valid hostname characters.
Maybe the future will bring the wildcard into the DNS world, should we consider such an option even if the RFC tends to minimize and containerize the options?

Thanks,
Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: ***@ngtech.co.il


-----Original Message-----
From: squid-users [mailto:squid-users-***@lists.squid-cache.org] On Behalf Of Alex Rousskov
Sent: Thursday, July 7, 2016 4:07 AM
To: squid-***@lists.squid-cache.org
Subject: Re: [squid-users] host_verify_strict and wildcard SNI
Post by Marcus Kool
Post by Steve Hill
I'm using a transparent proxy and SSL-peek and have hit a problem with
an iOS app which seems to be doing broken things with the SNI.
The app is making an HTTPS connection to a server and presenting an
SNI with a wildcard in it - i.e. "*.example.com". I'm not sure if
this behaviour is actually illegal, but it certainly doesn't seem
to make a lot of sense to me.
An SNI with a wildcard indeed does not make sense.
There are three rather different questions to consider here:

1. Is wildcard SNI "legal/valid"?
2. Can wildcard SNI "make sense" in some cases?
3. What should Squid do when receiving a wildcard SNI?


Q1. Is wildcard SNI "legal/valid"?

I do not know the answer to that question. The "*.example.com" name is
certainly legal in many DNS contexts. RFC 6066 requires HostName SNI to
be a "fully qualified domain name", but I failed to find a strict-enough
RFC definition of an FQDN that would either accept or reject wildcards
as FQDNs. I would not be surprised if FQDN syntax is not defined to the
level that would allow one to reject wildcards as FQDNs based on syntax
alone.


Q2. Can wildcard SNI "make sense" in some cases?

Yes, of course. The client essentially says "I am trying to connect to
_any_ example.com subdomain at this IP:port address. If you have any
service like that, please connect me". That would work fine in
deployment contexts where several servers with different names provide
essentially the same service and the central "routing point" would pick
the "best" service to use. I am not saying it is a good idea to use
wildcard SNIs, but I can see them "making sense" in some cases.


Q3. What should Squid do when receiving a wildcard SNI?

The first two questions are not really important and each may not even
have a single "correct" answer. I am sure protocol purists can argue
Post by Marcus Kool
Since Squid tries to mimic the behavior of the server and of the client,
it deserves a patch where instead of doing a DNS lookup and then doing a
connect (based on the result of the DNS lookup?),
Squid simply connects to the IP address that the client tries to connect to
and does the TLS handshake with the SNI (that does not make sense).
This way it mimics the client a bit better.
I believe that is what Squid does already but please correct me if I am
wrong.

When forming a fake CONNECT request, Squid uses SNI information because
that is what ACLs and adaptation services usually want to see. However,
I hope that intercepting Squid always connects to the intended
destination of the intercepted connection instead of trusting its own
fake CONNECT request.

Whether Squid should generate a fake CONNECT with a wildcard host name
is an interesting question:

1. A fake CONNECT targeting an wildcard name may break ACL-driven rules
and adaptation services (at least).

2. A fake CONNECT targeting an IP address instead of a wildcard name may
not give some ACL-driven rules and adaptation services enough
information to make the right decision.

3. A premature rejection of a connection with wildcard SNI does not
allow the admin to make the bump/splice/terminate decision.

#2 is probably the lesser of the three evils, but I wonder whether Squid
should also include the invalid host name as an X-SNI or similar HTTP
header in that CONNECT request, to give advanced ACLs and adaptation
services a better chance to work around known benign issues where the
admin knows the wildcard is not malicious (and to kill wildcard
transactions the admin knows to be malicious!).


A similar question can be asked about SNI names containing unusual
characters. At some point, it would be too dangerous to include SNI
information in the fake CONNECT request because it will interfere with
HTTP rules, but it is not clear where that point is exactly.


Cheers,

Alex.
Alex Rousskov
2016-07-07 16:23:46 UTC
Permalink
Post by Eliezer Croitoru
Maybe the future will bring the wildcard into the DNS world
- The results of standard queries where the QNAME contains "*"
labels if the data might be used to construct wildcards.
Alex.
Eliezer Croitoru
2016-07-07 21:28:11 UTC
Permalink
Thanks for clearing things out.
I suspect that at 1987 I wasn't able yet to understand English as I am now.
And also the Internet in my area at this year was something worth almost like GOLD.
So it seems that this is the first time of me actually encountering a case which a "hostname" was used with wildcard in it.

Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: ***@ngtech.co.il


-----Original Message-----
From: Alex Rousskov [mailto:***@measurement-factory.com]
Sent: Thursday, July 7, 2016 7:24 PM
To: Eliezer Croitoru; squid-***@lists.squid-cache.org
Subject: Re: [squid-users] host_verify_strict and wildcard SNI
Post by Eliezer Croitoru
Maybe the future will bring the wildcard into the DNS world
- The results of standard queries where the QNAME contains "*"
labels if the data might be used to construct wildcards.
Alex.
Steve Hill
2016-07-07 16:41:25 UTC
Permalink
Post by Alex Rousskov
Q1. Is wildcard SNI "legal/valid"?
I do not know the answer to that question. The "*.example.com" name is
certainly legal in many DNS contexts. RFC 6066 requires HostName SNI to
be a "fully qualified domain name", but I failed to find a strict-enough
RFC definition of an FQDN that would either accept or reject wildcards
as FQDNs. I would not be surprised if FQDN syntax is not defined to the
level that would allow one to reject wildcards as FQDNs based on syntax
alone.
Wildcards can be specified in DNS zonefiles, but I don't think you can
ever look them up directly (rather, you look up "something.example.com"
and the DNS server itself decides to use the wildcard record to fulfil
that request - you never look up *.example.com itself).
Post by Alex Rousskov
Q2. Can wildcard SNI "make sense" in some cases?
Yes, of course. The client essentially says "I am trying to connect to
_any_ example.com subdomain at this IP:port address. If you have any
service like that, please connect me". That would work fine in
deployment contexts where several servers with different names provide
essentially the same service and the central "routing point" would pick
the "best" service to use. I am not saying it is a good idea to use
wildcard SNIs, but I can see them "making sense" in some cases.
Realistically, shouldn't the SNI reflect the DNS request that was made
to find the IP of the server you're connecting to? You would never make
a DNS request for '*.example.com' so I don't see a reason why you would
send an SNI that has a larger scope than the DNS request you made.
--
- Steve Hill
Technical Director
Opendium Limited http://www.opendium.com

Direct contacts:
Instant messager: xmpp:***@opendium.com
Email: ***@opendium.com
Phone: sip:***@opendium.com

Sales / enquiries contacts:
Email: ***@opendium.com
Phone: +44-1792-824568 / sip:***@opendium.com

Support contacts:
Email: ***@opendium.com
Phone: +44-1792-825748 / sip:***@opendium.com
Alex Rousskov
2016-07-07 17:05:50 UTC
Permalink
Post by Steve Hill
Realistically, shouldn't the SNI reflect the DNS request that was made
to find the IP of the server you're connecting to? You would never make
a DNS request for '*.example.com' so I don't see a reason why you would
send an SNI that has a larger scope than the DNS request you made.
My DNS request was for coordinator.example.com. Since I wrote both sides
of the software, I know that the SSL server on that hostname will direct
me to the "best" internal *.service.example.com if I ask it to do that
by sending a wildcard SNI. That "SSL routing" will be based on some
internal business logic unavailable to the DNS resolver.

Is this design a good idea? No.

Is this bad idea "realistic"? Evidently, it is.

Alex.
Amos Jeffries
2016-07-07 20:01:30 UTC
Permalink
Post by Alex Rousskov
Post by Steve Hill
Realistically, shouldn't the SNI reflect the DNS request that was made
to find the IP of the server you're connecting to? You would never make
a DNS request for '*.example.com' so I don't see a reason why you would
send an SNI that has a larger scope than the DNS request you made.
My DNS request was for coordinator.example.com. Since I wrote both sides
of the software, I know that the SSL server on that hostname will direct
me to the "best" internal *.service.example.com if I ask it to do that
by sending a wildcard SNI. That "SSL routing" will be based on some
internal business logic unavailable to the DNS resolver.
Is this design a good idea? No.
Is this bad idea "realistic"? Evidently, it is.
Not really though. It depends on bugs in the receiving server software.
So even if it worked yesterday without a TLS proxy, it broke when the
server side of things changed.

Amos
Loading...