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!)
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).
