Great Circle Associates Firewalls
(July 1996)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: Secure Virtual Intranets
From: "Todd Glassey, Consultant" <tglassey @ earthlink . net>
Date: Fri, 05 Jul 1996 17:16:28 -0700
To: Firewalls @ GreatCircle . COM
Cc: Bill Stout <bill . stout @ hidata . com>
References: <199607051923 . MAA08347 @ osc . osc . hidata . com>
Reply-to: tglassey @ earthlink . net

IMHO - Bill, is generally right, I have some specific commentary but
like the idea of keeping the "autheticated" services inside the local FW
so that traffic to and from them can be simply encrypted as part of a
VPN architecture... As to the CA issues, hell x.509 and it's competitors
are simple enough, roll your own for internal uses!.

Bill Stout wrote:
> 
> What are the most widely used methods to create Secure HTTP/FTP
> Intranets over the Internet?
> 
> I can think of just a few off the top of my head:
> 
>    1.  Encryted PC-Firewall links.
>         a. Webserver must be inside firewall, guests must also
>         pass through firewall.
>         b. You must pay for/install/support encryption software.
>         c. Complete (IP) protocol stack encryption/access.

Use any of the commercial VPN based firewalls (SunScreen, Checkpoint, 
Raptor, Netcheck, etc...) .

> 
>    2.  Certificates on browser and server.
>         a. Webserver can be outside firewall.

I disagree, If the traffic from the Web Server is destined for sites
"ala Intranet" iot is much better to have this facility inside the
firewall. Otherwise the Web server must have some sense of encryption or
security services additional to it's own functionality.

>         b. No (additional) cost/support for client software

Possibly true unless SKIP or some other layered security approach is
used since this would mean an extra plug-in or layer particular to the
specific implementation.

>         c. Security is based on physical browser, not user.

Yes, sort of. 

>         b. Certificates must be requested from Verisign/RSA, or
>         private certificates created via Xcert software
>         (http://www.xcert.com/).

Not true of "Intranet" sites. Since the certificates are only to be used
inside the Known Computing Base (or "internal" topology) this is one of
the many instances where it makes sense to run a Mini C.A. for ones own
purposes.

> 
>    3.  HTTPS.
>         a. Webserver can be outside firewall.
>         b. No (additional) cost/support for client software
>         b. Intranet Username/Password authentication managed
>         separately from network authentication.
>         c. Multiple Intranet servers also managed separately.
> 

Not clean enough, IMHO. The overall "Security Paradigm" used should be a
part of a networking operations plan. Thus to keep the external point of
contact as homogeneous as possible is more cost effective from an ops
standpoint.



> Bill Stout
> <=======10========20========30========40========50========60========

---- SNIP ----

-- 
This email is from::
------------------
  Todd S. Glassey,    Consultant
          (415) 324-4318
Email:  tglassey @
 earthlink .
 com


References:
Indexed By Date Previous: Possible TACACS vulnerabilities?
From: Crocker Sean SSgt 786CS/SCBM <Sean . Crocker @ ramstein . af . mil>
Next: Re: P50 summary
From: Matthew Keenan <matt @ firstpac . com . au>
Indexed By Thread Previous: Secure Virtual Intranets
From: Bill Stout <bill . stout @ hidata . com>
Next: Re: Secure Virtual Intranets
From: Bernhard Schneck <Bernhard_Schneck @ GeNUA . DE>

Google
 
Search Internet Search www.greatcircle.com