Chattanooga
Unix
Gnu
Android
Linux
Users
Group

 

Hot Topics:

Sponsoring:

Odd EPB Behavior

From: AverageSecurityGuy 
------------------------------------------------------
I=92m sure that EPB does caching on its network but I=92ve not seen =
anything like this before. If you go to http://66.18.36.99/">http://66.18.36.99/ then you =
will get Google=92s home page. If you go to https://66.18.36.99/ then =
Firefox complains that the cert is only for *.google.com. Is this =
typical caching behavior or is EPB, MiTM Google?

--
Stephen Haywood
Owner, ASG Consulting
CISSP, OSCP
423.305.3700
asgconsulting.co




=============================================================== From: "Alex Smith (K4RNT)" ------------------------------------------------------ I'm not there so I can't say with 100% certainty that this is the case, but perhaps the certificate mismatch is due to you directly accessing the IP of the server, and your web browser got confused about the domain name of the cert vs. the IP you entered. Doesn't sound like anyone's ISP is at fault. I might be wrong, just a best guess. " ' With the first link, the chain is forged. The first speech censured, the first thought forbidden, the first freedom denied, chains us all irrevocably.' Those words were uttered by Judge Aaron Satie as wisdom and warning... The first time any man's freedom is trodden on we=E2=80=99re all damaged." - Jean-Luc Picard, quoting Judge Aaron Satie, Star Trek: TNG episode "The Drumhead" - Alex Smith - Dulles Technology Corridor (Chantilly/Ashburn/Dulles), Virginia USA t seen anything x

=============================================================== From: wes ------------------------------------------------------ This is expected behavior. HTTPS works by having a certificate with the name of the site you're supposed to be accessing. The IP address is not the usual name of that site, so it's not included in the list of valid names on the certificate. This is the reason we can only have 1 secure site on a web server: in order to have more, we have to have a single certificate with multiple names valid on it. This is hard to do, though some solutions have been coming out recently which make it easier. -wes

=============================================================== From: Dave Brockman ------------------------------------------------------ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 That is not technically correct (any longer). You can have more than one secure site on a server (and even on the same IP address and port, which is what I think you meant instead of server anyway), and SNI does not require a single certificate with multiple names. SNI is pretty well supported these days. Unless you're still on XP and only IE6. And realistically, lack of SNI support is the very least of your worries if that is you. Regards, dtb - -- "Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network." RFC 1925 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTFLn+AAoJEMP+wtEOVbcdKi4IAKRDfJ8pViYlX1bI7/TqMbRR b/enCs7wpyJ5nzB/QSsnZ1dn2S3N9aIiGKs0Ma1/O8O4cIq+TcgrRRDPw4M/eH9u 5t6PyBpnsdFfb5nzSmfrFvFhykUxvkYraLI6FkJu+FvE7b+pWZ0btw104T4hsWqV KzlMfHgsm7rc96w6l+xIBI3EkherBasqi5YS01ssqkARwChtZebud3RFIVJ0FXs2 3iG0rolwJNsHkB9yITHRXQ7PI5PpPJEL73HWsW0JexUNcgeeplB/NesDc5u7PRSY /vdvG0ova4TwJq89ynYLSWDnTov+R/yMifCoguCuJzo8uJ9CiVuVrVv1j8CVqyA= =V2mr -----END PGP SIGNATURE-----

=============================================================== From: Mike Harrison ------------------------------------------------------ order to have more, we have to have a single certificate with multiple = names valid on it. This is hard to do, though some solutions have been = coming out recently which make it easier. StartSSL.com does this VERY well, although they will run you through the = =93are we really sure we want to let you do this=94 wringer.=20 I got emails from intelligent real humans when I did it, they wanted to = know what I was doing and why.=20 Not all browsers like that behavior and will live you some warnings = depending on their security settings.=20 In the end, we got more IP addresses and put single domain wildcard = certificates up.=20 =97Mike=97

=============================================================== From: AverageSecurityGuy ------------------------------------------------------ I think you guys are missing my point. If I go to http://66.18.36.99 I = get Google=92s home page 66.18.36.99 is an EPB address. Typically a = caching server serves many URLs. I=92ve not seen a caching server = dedicated to one URL before. -- Stephen Haywood Owner, ASG Consulting CISSP, OSCP 423.305.3700 asgconsulting.co supposed to be accessing. The IP address is not the usual name of that = site, so it's not included in the list of valid names on the = certificate. order to have more, we have to have a single certificate with multiple = names valid on it. This is hard to do, though some solutions have been = coming out recently which make it easier. wrote: anything like this before. If you go to http://66.18.36.99/">http://66.18.36.99/ then you = will get Google=92s home page. If you go to https://66.18.36.99/ then = Firefox complains that the cert is only for *.google.com. Is this = typical caching behavior or is EPB, MiTM Google?

=============================================================== From: Dave Brockman ------------------------------------------------------ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I believe EPB has Google caching on-site, in which case it would not be odd for an EPB IP address to be serving up Google content. Google brought the infrastructure, EPB gave them IP addresses to stick on the infrastructure. That would make it easy to engineer traffic in such a way that Google traffic does not go over expensive uplink transit links. Regards, dtb - -- "Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network." RFC 1925 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTFL1ZAAoJEMP+wtEOVbcdpQYH/31lnmBVe4hZfb5G74B0S278 Ap8sq+k8Ek6D6gkAwuQXy6RevlHjo7/O7H65bt1i+uP5oyQp3e0JdTDFPpH10dmz BQmNAGVGBbUsOOo8g5yIVJZeufSEro4hrOjyYuszBGRyqEdhVdOS/Sz6C3OY1kqF r+UYvDJef6LZl8c3SFJzV+WGkROl7/J90HZukgbs1h3dsUb41T77kf7yTtbnkL4j gLT788spDt3ZQXf2WfxClO+QK4ey10WnfkN129kgJeX+opcwyMChzvhsrT+pKgg5 Eq6Git+M57b1nukZqj8MoKkq90WWNHMCqekYyi02EdXreZWD6Cd2LqBcn86jgp0= =Tbik -----END PGP SIGNATURE-----

=============================================================== From: AverageSecurityGuy ------------------------------------------------------ Thanks Dave. That makes sense. -- Stephen Haywood Owner, ASG Consulting CISSP, OSCP 423.305.3700 asgconsulting.co

=============================================================== From: Billy ------------------------------------------------------ Others have already explained this, but I think there can be another explanation. We use a lot of load balancers. Some are what's called wide Ip or global load balancing. That's a fancy word for "change DNS sometimes." Wide ip has hardware load balancers in two (or more) geographical locations. When you request a name, the time to live (ttl) for the name is set as such, that your resolver pretty much is forced to request from its delegation server, which then is forced to ask the root server chain, all the way down to asking the wide ip DNS appliance for the name (a lot of this DNS to DNS server talk is cached). So one minute you get an ip in Orlando. The next, an ip in Tampa. Conversely, connecting to that ip in Tampa routes you to one ip in a cluster of machines - in Tampa. So, you have one cert on 4, 10, or 100 machines. The only way to make that work is to connect to the DNS name that matches the Common Name (CN) on the cert. if you connect to say Orlandovip-www.company.com, the browser has no way to determine if Orlandovip-www is the same as www.company.com or not. If you DO want to use the ip for the cert name, I think you can if you make the reverse DNS look up match the forward DNS look up. Then if you connect to the ip, when the browser performs the reverse lookup, gets the name, and matches the name to the same ip using the forward lookup -- all the given names will match and everything is good. I'd have to test that, though. -- --b Sent from my iPhone

=============================================================== From: John Alcock ------------------------------------------------------ Google has Google Caches onsite within the EPB headend. The reason you are seeing the Security Cert is because you are accessing the IP directly and not through DNS. John

=============================================================== From: Dave Brockman ------------------------------------------------------ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does HTTP even do a RDNS lookup? If you want the cert valid when you access via IP address, the IP address needs to be either the CN or in the SAN attributes on the cert. Matching RDNS not required, I'm 99.9% certain. Most RDNS entries are more enlightening than 30.190.174.184. or 30.190.174.184.in-addr.arpa. Regards, dtb - -- "Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network." RFC 1925 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTFPKYAAoJEMP+wtEOVbcd6gAH/2hyck4B4BATYgWxGR9cXpXo ZKhRc3sJ/neJmCzI2MgvHeQrgn5ggsIsZepHvG4fCO0vhw8Zl/qYnjNEPfND8Xkw eSsZf+Ru3hARgrzY2KUmO7u+r0D2k1GOFFRVLdYP9YxKd6BYwR+NMHN0X14gP5YH ZNdgaAa3kh8xchFeq+ymILDEEjUy1Yfofv98gFbMsi6yPJiPGFqTFenTV2I59nE1 kfsKt4Ol5RXEOQpXGUUn8I6AfpkGiFrIzDvcQOKN+oSQK9hfjapYG9TLtDsKtiDK HMRAGOdzrX/GCE2wDb1jSom8xQYbAy7CJGnPoQImCAg7c0e39pRr8ORlpsACDzM= =TYY1 -----END PGP SIGNATURE-----

=============================================================== From: flushy@flushy.net ------------------------------------------------------ Quoting Dave Brockman : I just ran a quick test (and you are correct): [preparation] create two certs using my CA: cert1=CN=home-server-name cert2=CN=192.168.1.1 each server cert is a pair of server.pem and server.key, were key is an RSA 1024 bit key. [server command] openssl s

=============================================================== From: Billy ------------------------------------------------------ And yes. My fwd and rev DNS match. So my hypothesis was incorrect. My bad! --b

=============================================================== From: Mike Harrison ------------------------------------------------------ On Mar 3, 2014, at 12:30 PM, AverageSecurityGuy = wrote: get Google=92s home page 66.18.36.99 is an EPB address. Typically a = caching server serves many URLs. I=92ve not seen a caching server = dedicated to one URL before. The SSL Certificate appears to be a valid Google Cert signed by GeoTrust = as is the server I get when I see: https://www.google.com via ComCast at 173.194.37.20 Theories: EPB runs a local google server, saves lots of bandwidth, they possibly = share some ad revenue ?=20 or=20 EPB runs a fake local google server, so they can easily snarf your = credentials or monitor your google use beyond what they can do = otherwise.=20 Have you tried asking anyone clueful at EPB about it? =20 I cc=92d Shane Sexton just in case he still monitors that email address.=20=