[CLUE-Tech] apache & ssl problem

Mon Oct 29 06:29:02 MST 2001

On Sun, 28 Oct 2001, Dave Anselmi wrote:

> So telnet gets you the file, without encryption, without any apparent SSL handshake attempt?
>  Seems like you aren't really using SSL.  I assume you're using mod_ssl, not OpenSSL.

Yes, mod_ssl.  From the Apache Environment Section of phpinfo(), SERVER_SOFTWARE=Apache/1.3.19 
(Unix) (Red-Hat/Linux) mod_ssl/2.8.1 OpenSSL/0.9.6 DAV/1.0.2 PHP/4.0.4pl1 mod_perl/1.24_01.

> Your virtual host config is wrapped in an IfDefine - did you start Apache with something 
> like -DSSL to define it?  If not, the config isn't getting run.

I start and stop httpd via /etc/rc.d/init.d/httpd [start] [stop] [restart]

> If that isn't it, I can dig up an old SSL config I used to use - let me know.

As you mentioned earlier, port 443 is serving the file with no encryption.  I'll have a look at 
the mod_ssl configuration.  It appears from the apache info above that I'm using BOTH mod_ssl 
and OpenSSL...would that be the problem?

> Also, SSLVerifyClient require will require clients to have certificates which they usually 
> don't (unless you've got a way to give them out).  So maybe that isn't what you want.

Yeah, I'm limiting this site to a very few clients, I'll give them certificates.

> Finally, there are many bugs in the IE implementation of SSL that can cause it to fail with
> mod_ssl.  The workarounds include IE specific settings (SetEnvIF, which you have some of) and
> disabling some cipher suites.  You can check the mod_ssl mailing list of FAQ for details.  
> There can also be problems getting SCG to work on Netscape with Verisign certs.

I'll have to look into the IE specific settings, as I know all the clients will be IE 5.x

-- 

Cheers!

Randy Arabie

Received: from copper.americanisp.net (copper.americanisp.net [208.244.174.41])
	by clue.denver.co.us (8.9.3/8.9.3) with SMTP id TAA16594
	for <clue-tech at clue.denver.co.us>; Sun, 28 Oct 2001 19:21:38 -0700
Received: (qmail 6718 invoked from network); 29 Oct 2001 02:45:21 -0000
Received: from unknown (HELO sh01.shell.amisp.net) (216.38.38.12)
  by copper.americanisp.net with SMTP; 29 Oct 2001 02:45:21 -0000
Date: Sun, 28 Oct 2001 19:54:07 -0700 (MST)
From: Brad <brad at americanisp.net>
X-X-Sender:  <brad at sh01>
To: Dave Anselmi <anselmi at americanisp.net>
cc: <clue-tech at clue.denver.co.us>
Subject: Re: [CLUE-Tech] DSL QoS monitoring.
In-Reply-To: <3BDCB9CB.7DC05BEA at americanisp.net>
Message-ID: <Pine.LNX.4.33.0110281914560.14259-100000 at sh01>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: clue-tech-admin at clue.denver.co.us
Errors-To: clue-tech-admin at clue.denver.co.us
X-BeenThere: clue-tech at clue.denver.co.us
X-Mailman-Version: 2.0beta2
Precedence: bulk
Reply-To: clue-tech at clue.denver.co.us
List-Id: CLUE technical discussions, questions and answers. <clue-tech.clue.denver.co.us>

On Sun, 28 Oct 2001, Dave Anselmi wrote:

> Brad wrote:
>
> > Our diagnostic abilities are limited to a few critical
> > facts-
> > Does the user hit a DSL gateway on our facility?
> > Does the user hit our RADIUS authentication server?
> >
> > In all of these cases, the answers to the above questions
> > are both 'no'.  Qwest was simply not delivering the data to
> > our facility.  The user will show the line being trained,
> > but will not be able to authenticate or ping anything.
> > Qwest will say it it our fault because the customer's line
> > trains.  The process takes a minimum of three hours per
> > subscriber to diagnose with qwest's help.
> > Fortunately, Qwest only breaks about 2% of our customers.
> > Still enough to file weekly PUC complaints though.
>
> This is the sort of thing I was wondering about.  Unfortunately, I don't know much
> about ATM networks.  I'd like to be able to get some info out of my DSL modem (which
> seems to talk PPP over ATM, right?) to tell me whether my cells are getting to the
> ISP or not.

Unfortunately (as I understand it), Qwest has to be watching
the VPI to see the cell flow stats at the DSLAM and their
ATM Switches to determine if the cells are being passed
properly.  I find that 9 times out of 10, 'mirrored cell
flow' causes many of these problems.  Whereas- the exact
same packets are being sent back, that are recieved by the
ATM switch, always indicating a problem with the config of
that switch.

> I'd really like to be able to get my linux box to talk to Qwest's ATM switches - then
> I could probably get some answers.  But maybe that requires hardware I don't have
> (and maybe can't get) - would an internal DSL modem tell linux more than my external
> can tell me?

I dont think so- the way Qwest provisions subscriber
services would not allow access beyond the DSLAM port the
subscriber is attached to (on the ATM network).
Every subscriber has a VPI/VCP pair of either '1,1' or
'1,32' (for CAP and DMT connections).  But this is
re-translated to another ATM network in aggregate (again-
as I understand it, not a inteprise ATM technician hehe).
Then the data goes through that ATM network, to the ATM
switch that the provider is attached to.  So- the path is
re-translated, again, to another VPI/VCI pair on the
provider's end.
A pair of 1,465 for 'ISP A' would be a different customer
than 1,465 on 'ISP B's ATM circuit.
Therefore- I do not believe it is possible to gather any
additional ATM diagnostic data past "Is my data getting
to/from the DSLAM in the Central Office?"- usuall always the
case if the line actually 'trains' with that hardware.

> Anyway, if I knew how to use the DSL modem to do some ATM diagnostics, then I could
> decide whether to call Qwest or the ISP, and maybe Qwest would listen if I talked
> ATM-tech to them (I can always dream, can't I?)

Here is what I would recommend:
If the line does not train, call qwest.
If the line trains, but the LCP State is not open, call
qwest.
If the line trains, the LCP state is open, and the modem
has reached the 'remote gateway', then call the ISP.

You can find out the state of LCP by doing the following:
-Log on to the cisco
-enable
-type 'sh wan0-0'
You will see this line somewhere:
    PPP LCP State: Opened

> As it stands, all I can tell is whether I train to the CO, and whether I get a PPP
> connection to the ISP.  I had assumed that no PPP meant a Qwest problem and PPP but
> no Internet meant an ISP problem.  But I did see one where no PPP was the ISP's
> equipment.

If there is no PPP, then it is usually a Qwest issue- but
sometimes the ATM circuit at the ISP that you are
provisioned to may go down, which would cause the same
thing.. However- the ISP will definately be aware of the
problem and would be working with Qwest to repair it ASAP,
because you would not be the only customer affected by the
downed circuit.  Unfortunately- there are not redundant
provisions to Qwest's DSL ATM network- the providers are at
the mercy of Qwest to keep their hardware in working order.
Luckly, we have only seen three times where their ATM switch
fails and causes a major outage for some customers.

> Dave

Thanks,
Brad Baker
Director: Network Operations
American ISP
brad at americanisp.net
+1 303 984 5700 x12
http://www.americanisp.net/