Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (533)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Multiple-IP-Address clients - ISP problem? Crypto?  (Read 1202 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Posted 2003-10-05 14:25:21 »

Looking for ISP employees...Wink

We've got a situation where it appears that some ISP's actually spoof a different IP address for dialup users when they connect to http ports (80) or https ports (443)...is this really possible?

It sounds crazy, but it's playing merry hell with our token-based encryption schemes when a single HTTP client is connected to a server with two different IP addresses simultaneously!

I'm trying to find a different explanation, although it's difficult since the code's been locked down for two weeks and in that time the problem has repeatedly appeared and disappeared for certain individual users. I know that lots of ISP's have invisible WebCache's that drive me up the wall - it's really annoying when an updated webpage doesn't update because a webcache you can't avoid has incorrectly decided to serve the cached response (this has happened to me before - careful examination of all HTTP headers using a debugging HTTP client showed that the cache was ignoring the new timestamp on the webserver's response Sad ). Perhaps there's some good reason for using different IP addresses for encrypted / plaintext transmissions?

malloc will be first against the wall when the revolution comes...
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #1 - Posted 2003-10-05 22:44:19 »

Yes, no reason why they can't do that.

As for why they would do it, that's a different matter.  Maybe they log all port 80 traffic, and push it all out through a certain IP to get their logger to pick it up?  Don't bother with 443 as they can't do anything with the data anyway?  Maybe it's their simple and easy way of distinguishing non-cacheable data?

Have you ruled out the possibility that someone's trying a man-in-middle attack on your users' 443 traffic?

Hellomynameis Charlie Dobbie.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #2 - Posted 2003-10-06 12:26:15 »

Quote
Yes, no reason why they can't do that.

As for why they would do it, that's a different matter.  Maybe they log all port 80 traffic, and push it all out through a certain IP to get their logger to pick it up?  Don't bother with 443 as they can't do anything with the data anyway?  Maybe it's their simple and easy way of distinguishing non-cacheable data?


Yeah, I was imagining similar things - but really I'm just shooting in the dark here; I don't even know if it *is* the ISP, or if it's something else. We're working with dotted-quad IP's so there's no chance of DNS malarky going on, but I'm not sure if source-address-verification is currently enabled on the server (thinks: must check that now!)

Quote

Have you ruled out the possibility that someone's trying a man-in-middle attack on your users' 443 traffic?

[/quote]

The IP addresses concerned are from the allocated IP ranges of the ISP. Reverse-DNS suggests they are *all* modem-pool servers. Interestingly, the http and https connection IPs are from completely different IP blocks, and the https IPs are not en route between client and server via ICMP - but are only one hop away, suggesting possibly that the modem dialup server is multi-homed in two unrelated IP blocks, and uses a different NIC dependent on traffic.

As yet we've not *confirmed* there's no attack going on (c.f. above re: SAV), but we do have access to one affected client, so have been able to gather the above details. I'm now wondering if perhaps there's a hardware web accelerator device (a hardware cache?) on the modem server (hence the extra IP); or perhaps it's modem pool doesn't bother with data compression when it knows you're using encrypted streams (and the modem hardware is configured to notice this based on IP address).

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #3 - Posted 2003-10-09 14:49:49 »

Quote
Looking for ISP employees...Wink

We've got a situation where it appears that some ISP's actually spoof a different IP address for dialup users when they connect to http ports (80) or https ports (443)...is this really possible?


As it turns out, what happened is that a major ISP changed their webcache configuration. The previous setup had either routed all http* traffic via their caches, or none - but now they route http through the cache, everything else not.

I'm not sure what they're doing with their LAN setup in the modem pool, but the modem dialup server is one hop across PPP - and so is the webcache (i.e. web packets do NOT go through the dilaup server on their way to the webcache). I'm confused by this because I thought PPP was point-to-point only (hence PP Protocol?), not point-to-multipoint?

Anyway, what happened was that we were getting IP addresses for the PPP dialup servre (on SSL HTTP) and for the webcache (on HTTP) simultaneously- hence the difference. Obvious really; it's just that PPP bit that's still confusing me.

malloc will be first against the wall when the revolution comes...
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (26 views)
2014-07-24 01:59:36

Riven (25 views)
2014-07-23 21:16:32

Riven (19 views)
2014-07-23 21:07:15

Riven (22 views)
2014-07-23 20:56:16

ctomni231 (51 views)
2014-07-18 06:55:21

Zero Volt (46 views)
2014-07-17 23:47:54

danieldean (37 views)
2014-07-17 23:41:23

MustardPeter (40 views)
2014-07-16 23:30:00

Cero (56 views)
2014-07-16 00:42:17

Riven (55 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!