Master of Science Thesis

1
Master of Science Thesis

• Secure Collaborative Web Browsing and Chat
  Through Standard Web Pages
• By
• Patricia Ferrao
• November 22, 2004

2
Thesis Work

• Researched collaboration over the internet
• Researched existing frameworks and products
• Discovered limitations of existing systems and
  investigated solutions
• Built a prototype that incorporates solutions to
  existing limitations
• Architecture and design
• Implementation
• Performance testing
• Documented discoveries
• Proposed areas for future work

3
Presentation Outline

• How people collaborate over the internet
• Existing collaborative solutions in the research
  and commercial arenas
• Limitations of existing collaborative solutions
• Contrasting technologies and topologies for
  building collaborative solutions
• Prototyping a proof-of-concept that addresses
  existing limitations
• Requirements, architecture, implementation, and
  performance evaluation
• Lessons learned
• Future work
• QA
• Demo

4
How People Collaborate Over The Internet

• Asynchronous systems
• Email, newsgroups, file transfer, Web pages
• Synchronous systems
• IM, chat and presence
• Audio/video conferencing
• Whiteboard
• Collaborative editing
• Collaborative presentations
• Collaborative Web browsing
• Application sharing, distance learning, team
  rooms

5
Collaborative Solutions From The Research
Community (1)

• Habanero
• Developed by NCSA
• Java-based platform
• Enables Java applets and applications in a
  distributed environment
• Broadcasts user actions to all participants
  (serialized objects/centralized server)
• Client-side APIs allow apps to share events with
  server
• Server provides arbitration and networking
• Sample applications provided include
• Whiteboard, chat, Mosaic-based collaborative Web
  browsing

6
Collaborative Solutions From The Research
Community (2)

• Groupkit
• Developed at the University of Calgary, Canada
• Based on TCL/TK
• Uses TCLs built in networking socket commands
• Decentralized replicated architecture, but
  central session server required
• Session manager and conference applications
  running on each machine
• Provides APIs for groupware widgets
• Sample applications provided include
• Multi-user text editor, whiteboard, collaborative
  web browsing

7
Collaborative Solutions From The Research
Community (3)

• Coca
• Developed at UCLA
• Distributed framework based on IP multicast
• Provides its own scripting language
• Supports applications written in any programming
  language
• Sample application provided
• Whiteboard application
• Copy of Coca VM runs at each client site
• Framework provides
• Data distribution
• Access, floor, and concurrency control

8
Collaborative Solutions From The Research
Community (4)

• ESIC
• Developed by Vincent W. Merlin, UCCS
• Based on Akamais ESI and content delivery
  network
• Client interface uses XML
• Supports client-server and proxy-server
  architectures
• Communicates over HTTPS
• Sample applications provided include
• Java applet used for collaborative drawing
• Supports hosted communication through a central
  server and peer2peer through proxy servers
• Framework for definition of communication
  channels, user roles, and session permissions

9
Commercial Collaborative Solutions
10
Pitfalls of Existing Solutions

• Most not firewall-friendly
• All require extra installation or some form of
  mobile code for client
• Many not platform independent

11
Internet Collaboration Technologies

• Looking For
• Trusted client-side technology that penetrates
  firewalls
• Open-source technology
• Usability
• Platform-independence
• Ubiquitous access
• Easy to use
• Scalability and robustness

12
Network Architecture

• Client-server
• Client initiates connection and server provides
  response
• Pure client-server model server never initiates
  connection
• Collaborative communication between clients goes
  through one or more servers
• Advantage central control.
• Disadvantages scalability and robustness
• Peer-to-peer
• All nodes equally client and server and redundant
• No central control
• Advantage robust
• Disadvantages no central control, scalability
  and concurrency issues

13
Client-Server ModelHierarchical Topology

• Highly scalable (eg. DNS)
• Can add levels and nodes per level
• Tree can be rebalanced
• Root is vulnerable
• Not robust

14
Atomistic Peer-To-Peer

• Very distributed
• Node discovery via invitations and advertisements
• All nodes perform the same function
• All nodes are redundant
• Advantage highly robust
• Disadvantages scalability and security are
  difficult, lack of central control and
  concurrency control

15
Load Balancing - DNS

• Authoritative DNS can be configured to resolve a
  Domain Name into multiple IP addresses
• Addresses can be used in round robin
• Caching lengthens IP address propagation through
  Internet
• Advantages easy, cheap, servers located anywhere
  on Internet
• Disadvantages no load feedback from servers, not
  robust, difficult to maintain session
  persistence, and DNS caching

16
Load Balancing - Hardware

• Hardware sitting in front of a server cluster
• Provides single IP address to clients
• Uses IP header, URL data, cookie information, and
  server load to forward requests
• Changes packet information for correct forwarding
• Advantages Tightly coupled with server nodes,
  can acquire load information
• Disadvantages Separate hardware, single point of
  failure, potential traffic bottleneck, cant
  easily handle SSL traffic to decipher session
  info

17
Load Balancing - Dispatcher

• Web server sitting in front of server cluster
• Provides a single IP address to the outside
• Redirects requests to nodes based on rules, load
  information, HTTP header, URL data, and cookies
• Redirection through packet rewriting, packet
  forwarding, and HTTP redirection
• Advantages Easily handles SSL traffic to read
  HTTP header
• Disadvantages Can become single point of failure
  and traffic bottleneck

18
Secure Client TechnologyFirewalls and Proxies

• Firewalls prevent unwanted traffic from entering
  a network
• Packet-filtering firewalls filter each packet
• Source/destination, and TCP/UDP ports
• Proxy firewalls provide session-level filtering
• NAT mapping multiple internal IPs to one
  external IP
• Only HTTP/HTTPS easily penetrate firewalls, since
  all firewalls open ports 80 443 for outgoing
  connections
• NAT poses extra problems for protocols such as
  SIP and H.323

19
Secure Client Technology Mobile Code

• Mobile code embedded in a Web page gets
  downloaded when browser renders a page
• Active-X controls have no security can crash a
  machine or reformat hard drive
• Active-X security model based on digital
  signature, but it isnt enough
• Applets provide better security, but a digital
  certificate can enable them to leave the sandbox
• Unsigned applet can hog client memory or fake an
  email
• Plug-ins can get stored on hard drive, and get
  loaded into RAM when browser gets a mime-type
  request
• Plug-ins can take advantage of OS capabilities
  and low-level functionality
• All three can be blocked by a browser or at a
  firewall

20
Secure Client Technology JavaScript

• Client-side scripting language that can be
  embedded into HTML pages and rendered by the
  browser
• Very limited in what resources it can access
• Privileges can be extended via signed JavaScript
• Can be blocked by browser not done since used
  extensively
• DOD does not allow applets, Active-X, or
  Plug-Ins, but allows JavaScript

21
Prototype

• Goal
• Prototype a collaborative web app that addresses
  major issues (CoWebBROWSE)
• Requirements
• Secure, trusted client technology
• No installations, mobile code, cookies, or
  pop-ups
• Ubiquitous access and ease of use
• Platform independence
• Free, open-source technology
• Scalability
• Basic Web browsing collaboration features

22
Architecture
   
 
 
 
Directory Server
Second-Order Session Servers
       
First-Order Client Servers

Clients
23
CoWebBROWSE Client Display
24
CoWebBROWSE Technology
Tomcat
MySQL
Legend Directory Server Database Client
Servers Session Server Clients
HTTP
JDBC
Tomcat
Tomcat
Tomcat
HTTP
HTTP Postlets
HTTP Pushlets
HTTP
Netscape
Netscape
Netscape
25
CoWebBROWSE PrototypePushlet Framework

• Open source written by Just Van Den Broecke, Just
  Objects B.V.
• Multiple Java Servlets interacting (Postlets and
  Pushlets)
• Clients communicate with server over HTTP
• Pushlets
• Allow server to push events to a browser in real
  time
• Keeps client connection alive as long as client
  stays in the session
• Postlets
• Allow browser to send events to the framework

26
Why Pushlet is Different

• Allows client to initiate one HTTP connection,
  and have server respond with information
  piecemeal, as it becomes available, over an
  indefinite period of time (server push)
• No need for multipart mime type (not supported by
  IE)
• No need for keep-alive (requires browser time-out
  to be set very high, server must know exact
  content length, server buffers response)
• No need for client pull
• No need to have server initiate connection to
  client (extra ports, applets)

27
CoWebBROWSE PrototypeLogin Function
Passes login parms
Passes login parms for validation
On Directory Server
On Client Server
LoadBalanceTag.java
CoWebBROWSE service page
Calculates URL of client server, and adds client
server page to frame
Start Here
Gets login parms from user
28
CoWebBROWSE PrototypeClient DHTML Frames

• Six visible frames

• Two hidden Frames
• Pushlet frame communicates with pushlet servlet
• Postlet frame communicates with postlet servlet

29
CoWebBROWSE PrototypeExpanding JavaScript
Privileges

• JavaScript DOM model only allows same domain
  frames to interact
• Netscapes JavaScript signing technology can
  expand this interaction
• Netscapes signtool is freely-available
• Netscape communicator, signtool, and digital
  certificate required for code signing
• User is notified and must give permission
  whenever signed JavaScript is requesting expanded
  privileges from browser

30
CoWebBROWSE PrototypeWhy Expanded Privileges
www.cnn.com
CoWebBrowse.htm_at_
Link http//www.cnn1.com
Sanluis.uccs.edu

• User clicks on link
• Browser retrieves www.cnn1.com and displays in
  coBrowse frame
• CoWebBrowse.html gets onload event that
  coBrowse frame reloaded
• CoWebBrowse.htm needs to ask browser for coBrowse
  frames new URL in order to send it to server
• ISSUE JavaScript security prevents the
  interaction

31
CoWebBROWSE PrototypeExpanded Privileges
(Example)

• function displayLocation()
• netscape.security.PrivilegeManager.enablePrivileg
  e("UniversalBrowserRead")
• var loc frames'browseSpace'.location.href
  
• ltframe src http//sanluis.uccs.edu8289/CoWebBro
  wseProj/html/signdir/BrowsingFrame.html name
  "browseSpace" onload"displayLocation()" /gt
• lt/framesetgt

32
CoWebBROWSE PrototypeLoad Balancer
Implementation

• Consists of a JSP tag library and a servlet
• Makes use of two DB tables (servers and groups)
• Tag library code provides
• login authentication
• session initiation and management
• load balancing at client-server and
  session-server
• Servlet accepts load information from session
  servers and updates database with new load data
• Both tag library code and servlet code access DB
  via JDBC
• Client-server load balancing is least-load LRU

33
CoWebBROWSE PrototypeClient-Server
Implementation
34
CoWebBROWSE PrototypeSession-Server
Implementation

• Composed of two servlets, Level2Post and History
• Level2post receives events from client-servers
  and propagates to all client servers in session
• Session server keeps track of all client-servers
  and active client participants in a session
• Session server keeps track of active cobrowsed
  URL for a session
• History servlet takes a history request from
  client and returns session history information
• History response is in XML format

35
CoWebBROWSE Advantages (1)

• Ubiquitous Access
• Uses trusted client technology
• JavaScript, regular browser, no installations, no
  mobile code, no cookies, no pop-ups
• Uses HTTP(S), ports 80 and 443.
• Uses Netscapes signed JavaScript technology to
  expand client privileges
• Client is platform-independent

36
CoWebBROWSE Advantages (2)

• Load Balancing
• Tightly coupled with implementation
  (client-server LB based on number of active
  pushlet connections session server LB based on
  round robin or load info)
• Limits hierarchy to two levels by keeping a
  session on a common session server
• Tomcat clustering can be used to alleviate single
  point of failure.
• Can increase robustness by keeping a heartbeat
  with client-servers and session-servers
• Network Architecture
• Hierarchical client-server model is highly
  scalable
• There are multiple roots in hierarchy for
  improved robustness
• Load balancing algorithm improves scalability and
  robustness

37
Key Technical Challenges

• Use of signed JavaScript
• Limited documentation as a result of low
  penetration
• Not working with new version of Mozilla (1.7)
• Tomcats support for pushlets
• Tomcat limits the number of simultaneous servlet
  connections to 10

38
Performance Evaluation
Crestone
Sanluis MySQL
Legend Directory Server Database Client
Servers Session Server Clients
Tomcat v5.0.18 Linux RHAT rls9 Client Mozilla 1.5
on WinXP
HTTP
JDBC
Shavano
Blanca
Wetterhorn
Sanluis
HTTP
HTTP Postlets
HTTP Pushlets
HTTP
Mozilla Version 1.5 For Windows
39
CoWebBROWSE Testing

• Testing included the use of chat messaging
• Compared time deltas between messages entering a
  client-server postlet and exiting a client-server
  pushlet
• Averaged the results of six test executions
• Timing measurements tabulated for
• One client on one client-server
• Two clients on two client-servers
• Three clients on three client-servers
• Seven clients on one, two, and three
  client-servers
• Fourteen clients on two client-servers
• Twenty-one clients on three client-servers

40
CoWebBROWSE Test Results
Number of Users vs. Client-Servers
User Wait Times Vs. Number Of Client Servers (7
Clients)
41
Compatibility Test Results
Co-Browse works, but part of page content may be
different for each client
42
Lessons Learned

• Signed JavaScript difficult to work with (IE does
  not currently support it for example)
• Limitations of persistent HTML connections
  through pushlets
• Trusted client-side technology implicitly has
  limited power (would be difficult to add
  voice/video for example)
• May need to choose least intrusive technologies
  available that can still do the job (ie. Applets
  vs Active-X or plug-ins, tunnel SIP or H.323 over
  HTTPS)

43
Future Enhancements

• Investigate why Tomcat only supports 10
  concurrent connects
• Investigate why latest version of Mozilla doesnt
  work
• Investigate how to make the application work with
  IE
• Investigate how to add voice, data, and a group
  pointer
• Investigate what it would take to make the
  application work on a wireless device such as a
  smart phone or PDA
• Investigate what it would take to make the
  application work with other applications, such as
  Adobe Acrobat, PowerPoint, and complex Javascript