Secure Remote Access to an Internal Web Secure Remote Access to an Internal Web ServerServer

Christian Gilmore, David Kormann, and Aviel D. Rubin

ATT Labs - Research

“The security policy usually amounts to total trust of all insiders and total mistrust of outsiders, where the firewall defines the

boundary.”

2

OutlineOutline

• Requirements vs. the current architecture constrains.• Proposed solution.• Security assessment of the proposed solution.• Conclusion.• Questions.

3

RequirementsRequirements

• Access to the internal web server from outside of the firewall boundary.

• Proposed solution should not involve – changes to the firewall configuration on the network or...– changes to the firewall policies

4

EnvironmentEnvironment

• Firewall– “[Inside user] …can establish TCP connection to hosts

outside the firewall on any port, while inbound connections are tightly restricted.”

– “[Firewall] … tears down inactive connections every 15 min.”• DWT (dumb Web Terminal)

– “We strive to treat the DWT as “untrusted” as possible”

5

Possible of the shelf solutionsPossible of the shelf solutions

• Telnet or text-based browser such as Lynx– Disadvantage:

• HTML travels in plain text over the network• No support for multimedia

• Tunneling protocols (IPSpec, SSLtelnet).– Disadvantage:

• requires advance access to the remote client browser settings and computer settings.

6

ArchitectureArchitecture

Internet

DWT

Proxy

Authentication

Server

Web

Server

Firewall

7

ProxyProxy

PushWeb Absent DWTWeb

Server Firewall

Control Connection

Data Connection

Web Request

Web Reply

Web Request

Web Reply

8

Authentication and SecurityAuthentication and Security

• User Authentication

– Hash Chaining– User has to re-enter password every 20 minutes

• Connection Confidentiality

– HTTP over SSL - Secure Socket Layer.

9

ProxyProxy

PushWeb Absent DWTWeb

Server

Firewall

Control Connection

Data Connection

Web Request

Web Reply

Web Request

Web Reply

SSL Session

10

Connection ConfidentialityConnection Confidentiality

• After the user was successfully authenticated the PushWeb establishes the SSL connection to the DWT.

• The SSL on the Server is configured to restrict the set of ciphers supported only to those that provide USA domestic-quality encryption.

11

Security AssessmentSecurity Assessment

• Compromise of Absent– DoS attack - not preventable– Eavesdrop on the user session - SSL prevents it.– Replay attack - SSL makes it almost impossible.– Spoofing - user must check SSL certificate.– Obtain root on PushWeb or access the internal web:

• data cannot be moved over control connection• the same effort as from any other outside host

12

Security Assessment (Continued)Security Assessment (Continued)

• Compromise of PushWeb– PushWeb has limited access rights on the network– No other services are available from the PushWeb– No user data stored on the PushWeb

13

ConclusionConclusion

• The solution achieved its goal:– No changes were required to the network infrastructure– The system provides “...internal Web access from sites such

as terminal rooms and Internet cafes.”

• The system is using well tested protocols - one time password and SSL, but “… protocol composition is a very hard problem and has led to security problems in the past.”

14

QuestionsQuestions

• To overcome the firewall policy authors used PushWeb / Absent configuration. Is there any security gain in connecting through Absent machine as oppose to connecting straight through a firewall?

• If there is a gain, than against what type of attacks?

Internet

DWT

SSL

Web

Server

Firewall

PushWeb Absent