[ic] proxy servers receiving 403 errors. WideOpen and TrustProxy

[John1]

Recently a customer mentioned to us that they were unable to access our site
one day because they were getting an access denied page back from the
webserver.

On inspection of the web log I noticed there were quite a lot of "status
403: Forbidden" entries.  Closer inspection revealed that these errors were
only ever served up to cache/proxy servers.

Here are some examples of hostnames showing 403 errors:

cache-loh-ac06.proxy.aol.com
glfd-cache-2.server.ntli.net
manc-cache-2.server.ntli.net
leed-cache-2.server.ntli.net
lutn-cache-1.server.ntli.net
lutn-cache-3.server.ntli.net
cache1-popl.server.ntli.net
bagu-cache-1.server.ntli.net

>From reading around I am guessing that I need to use one of WideOpen,
TrustProxy or DomainTail in the catalog.cfg file to disable IP qualification
of user sessions?

We use a real-time payment gateway (via an SSL encrypted page) and PGP
encrypted credit card information.  Does this mean that the best approach
would be to use "WideOpen Yes"?

I still don't feel I fully understand the reason for the 403 errors, or the
best way to get over these proxy server problems:

1) Does this mean that the session id is the *only* thing used to identify
session data?  Does this mean that anyone from any PC in the world could
provide the same session id as an argument to their URL and they would then
be able to see another customer's address details?  Or, would the fact that
the address details are only visible from a secure SSL page prevent this
anyway?

2) Should I set SessionExpire to say 20 minutes?  Is this the length of time
after the *last* request that the session will expire.  i.e.  Will the
session only expire if the user *stops* browsing the website for a period of
more than 20 minutes?

3) Is "WideOpen Yes" only necessary for compatibility with browsers who have
session cookies disabled?  i.e. Do proxy servers still cause a problem for
users who have session cookies enabled?

4) Is there a better or different way to solve these 403 errors, or is is
"WideOpen Yes" the way to go?

5) The site uses SSL pages for taking order & payment details, credit card
numbers are PGP encrypted, and a real-time payment gateway is used.  In this
situation, does "WideOpen Yes" still present any security risks that we
should be concerned about?  If so, is there anything else we can do to
mitigate against them?

>From all of the above, am I right to conclude that all customers of ISPs who
employ proxy servers will have intermittent problems accessing the site
unless "WideOpen Yes" is used?

Any help or insight into the above would be greatly appreciated.  Thanks.