On 16/05/2015 6:22 p.m., Walter H. wrote: > On 16.05.2015 01:41, Amos Jeffries wrote: >> On 16/05/2015 6:14 a.m., Walter H. wrote: >>> Hello, >>> >>> is IPv6 somewhat similar to IPv4? >> Somewhat, yes. > I just wondered because of the "different" behaviour; >>> e.g. >>> >>> I would write >>> >>> acl block_ipv4_range dst 84.84.84.0/24 >>> deny_info errorpage block_ipv4_range >>> http_access deny block_ipv4_range >>> >>> to block any hosts within this IPv4 range >> Taking a step asside, that is not quite what those rules do. They block >> access from anywhere *to* the IP address range (TCP/IP packet >> destination on the request messages). >> > yes this should be the intention, that you get an error (in this case > the errorpage) when > you have e.g. http://84.84.84.2/ or https://84.84.84.2/ as URL in your > browser ... It will block that, and any domain name which resolves to those IPs. >> If you were trying to prevent those hosts themselves from accessing >> anything through the proxy you need the "src" ACL type. > I know; >>> how would be the syntax for blocking any hosts within a specific IPv6 >>> subnet >>> e.g. [2408:8000::]/24 >> FYI the [] syntax is URL format - for uses when a port may exist. So the >> ':' between IP:port dont get confused. >> > I noticed the difference, but wondered why e.g. /etc/hosts.deny contains > this: > sshd: [2408:8000::]/24 It differs by program. Depends on how v6-experienced the developer who wrote the code was. There are some new to IPv6 seems to think they always have to use []. Same as there are people who believe every domain name begins with www, or email addresses have to contain alphanumerics. > >>> should it be this? >>> >>> acl block_ipv6_subnet dst 2408:8000::/24 >>> deny_info errorpage block_ipv6_subnet >>> http_access deny block_ipv6_subnet >> Yes. Though the /N CIDR range is probably different. An IPv4 /24 is >> equivalent to an IPv6 /52 (255 separate pieces of hardware with a >> mandatory /64 each). >> > why I'm asking, because; when having both sections in squid.conf and > doing SSL-bump > you get a different reaction in the browser: > > https://84.84.84.22/ > brings the 'errorpage' as expected > the generated certificate has the IP-address (84.84.84.22) as its common > name; > > but > https://[2408:8000::3]/ > behaves different in various browsers: > > - IE 7: brings a certificate error, when accepting you get the errorpage > the generated certificate has the IP-address 2408:8000::3 as > its common name > > - later FF (17+) do nothing, older FF (3.6) bring > "The proxy server is refusing connections > Firefox is configured to use a proxy server that is refusing > connections." > > - Chrome 42 brings ' Your connection is not private' and > NET::ERR_CERT_COMMON_NAME_INVALID > when clicking advanced and proceed with warning you get the errorpage > the generated certificate has the IP-address 2408:8000::3 as > its common name > > trying https://[2408:8000:0:0:0:0:0:3]/ does an automatic reduction to > https://[2408:8000::3]/ by the browser > > does it seem to be problematic, when having an TLS-server with an IPv6 > address only without DNS, because of the comm name? That is a different issue entirely. X.509 certificate format explicitly states that the field contains the domain name registered to the entity the certificate was issued to. There are certain things that are done with it that can only be done with a domain name (wildcard validation, domain name comparisons, etc). Going by that description it seems Firefox and Chrome are a bit broken. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
