can you internally proxy a request more than once?

[Brian Julin]

Phil Mayers wrote:

> I'm not entirely sure I buy that it ensures only the outer server is
> affected; once compromised, the outer server can be used to send
> arbitrary UDP packets to the inner server since the sockets are already
> open. But I guess the same could be said of any perimeter defence
> architecture.

True, it's just one layer.

>> You still have some unnecessary code surface exposure what with EAP being
>> processed on the internal server (unless you were to manage to somehow get
>> tunneling of unwrapped MSCHAP working and do the EAP unwrap on the
>> external server.)

>If you were going to do that, I would strongly recommend *not*
>transforming EAP-MSCHAPv2 into plain MSCHAP; the code that does this is
>hairy.

In an exercise of folly I did try that.  Then I tried letting it rewrap the EAP,
but it didn't seem up for the task.  Left it for future dull days.

> Normally I wouldn't be quite so bug-paranoid, but RADIUS is tied pretty tightly
> to the most security-sensitive and mission-critical systems we have.

> As in... what? It authenticates against your password database? I would
> have thought that all the internet-facing web properties would be rather
> more of a risk than radius requests coming from hosts with a shared secret.

Well, I shouldn't go into that on a public forum.  As far as SSO web services,
there are things I'm responsible for, and things I am not.  I don't worry too
much about the latter :-)

> I'm wondering if you would feel all this was necessary if RadSec were in
> use?

It is.  Some decade from now it is also possible RadSec within eduroam will
migrate to a more (PKI-based) peer-to-peer model, so if anything that's more
hosts we'd be talking to.

> (As an aside, while the virtual server functionality is very useful when it comes
> to providing an integrated inner/outer tunnel solution, I've found it much more
> convenient to administer discrete usage cases with individual instances.  Then
> you can do work on one server without worrying that a change will somehow
> have unintended consequences on other services when you reload the config.)

> This is something that we *do* use. Basically I have separate processes
> for wired macauth, local wireless/wired 802.1x, eduroam visited/SP,
> eduroam home/IdP, vpn mschap and so on.

Same here, but the eduroam instances are each split into two (a 3.0 for
radsec/filter and a system stock version for the internal.)  The SP instance
also allows our users to gain the same privileges (and be subject to the
same NAC criteria) as they would on the normal SSID.  That way they
can configure for eduroam and never have to mess with changing
profiles, but it also means that a crash of the instance that does this
local authentication will strand my users and then the pitchfork closets
will be raided, so I'd rather any problems that might occur when a guest
makes us talk to the federation were isolated to guests only.

> The main reason is fault isolation; a long while ago (several years now)
> the occasional crash bug would surface in either the TLS or SQL code,
> and it was useful for this to be confined.

This is the most tangible benefit, yes.  Helps me sleep much sounder.