Document 7332780
Download
Report
Transcript Document 7332780
Master of Science Thesis
Secure Collaborative Web
Browsing and Chat Through
Standard Web Pages
By
Patricia Ferrao
November 22, 2004
5/23/2016
1
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
5/23/2016
2
Presentation Outline
1.
2.
3.
4.
5.
6.
7.
8.
9.
5/23/2016
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
Q&A
Demo
3
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/23/2016
4
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:
5/23/2016
Whiteboard, chat, Mosaic-based collaborative Web browsing
5
Collaborative Solutions From The
Research Community (2)
Groupkit
Developed at the University of Calgary, Canada
Based on TCL/TK
Uses TCL’s 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:
5/23/2016
Multi-user text editor, whiteboard, collaborative web browsing
6
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:
Copy of Coca VM runs at each client site
Framework provides:
5/23/2016
Whiteboard application
Data distribution
Access, floor, and concurrency control
7
Collaborative Solutions From The
Research Community (4)
ESIC
5/23/2016
Developed by Vincent W. Merlin, UCCS
Based on Akamai’s 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
8
Commercial Collaborative Solutions
Technology
Features
Architecture
Firewall
Friendly
Client
Platform
Independent
MS
LiveMeeting
HTTPS
Chat,
whiteboard,
presentations,
no audio/video
Central
yes
Browser,
plug-in
yes
MS
NetMeeting
.NET, H.323,
T.120
Video, audio,
chat,
whiteboard
Central
no
Application
to be
installed
Windows only
MS Messenger
SIP, .NET
Video, audio,
IM
Hybrid central/
peer2peer
no
Application
to be
installed
Windows only
WebEx
T.120, H.323,
SIP, LDAP,
HTTP, own inhouse
protocols
Video, audio,
chat, Emeetings,
presentations
Central
Yes
HTTPS
tunneling
Browser,
cookies,
requires
download
of exe file
yes
Click-To-Meet
Active-X,
H.323, T.120,
SIP, HTTP
Video, audio,
E-meetings,
presentations
Central
Yes
HTTPS
tunneling
Webbased
client that
uses
Active-X.
Must be
downloade
d and
installed.
Windows only
5/23/2016
9
Pitfalls of Existing Solutions
Most not firewall-friendly
All require extra installation or
some form of mobile code for client
Many not platform independent
5/23/2016
10
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
5/23/2016
11
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:
5/23/2016
All nodes equally client and server and redundant
No central control
Advantage: robust
Disadvantages: no central control, scalability and concurrency
issues
12
Client-Server Model:
Hierarchical Topology
Highly scalable (eg. DNS)
Can add levels and nodes per level
Tree can be rebalanced
Root is vulnerable
Not robust
5/23/2016
13
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
5/23/2016
14
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
5/23/2016
15
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, can’t easily handle
SSL traffic to decipher session info
5/23/2016
16
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
5/23/2016
17
Secure Client Technology:
Firewalls and Proxies
Firewalls prevent unwanted traffic from entering a
network
Packet-filtering firewalls filter each packet:
Proxy firewalls provide session-level filtering
Source/destination, and TCP/UDP ports
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
5/23/2016
18
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 isn’t
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
5/23/2016
19
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
5/23/2016
20
Prototype
Goal:
Prototype a collaborative web app that addresses major
issues (CoWebBROWSE)
Requirements:
5/23/2016
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
21
Architecture
Second-Order
Session Servers
Directory
Server
First-Order
Client Servers
Clients
5/23/2016
22
CoWebBROWSE Client Display
5/23/2016
23
CoWebBROWSE Technology
Legend:
Directory Server
Database
Client Servers
Session Server
Clients
MySQL
Tomcat
HTTP
Tomcat
HTTP Postlets
Tomcat
JDBC
HTTP
Tomcat
HTTP Pushlets
HTTP
Netscape
5/23/2016
Netscape
Netscape
24
CoWebBROWSE Prototype:
Pushlet 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:
5/23/2016
Allow browser to send events to the framework
25
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)
5/23/2016
26
CoWebBROWSE Prototype:
Login Function
Passes login
parms for
validation
On Directory
Server
Passes login
parms
On Client
Server
LoadBalanceTag
.java
CoWebBrowse.htm
LoadBalance.jsp
Login.jsp
LoginFrame
.html
Gets login parms
from user
5/23/2016
Start
Here
Calculates URL of
client server, and
adds client server
page to frame
CoWebBROWSE
service page
27
CoWebBROWSE Prototype:
Client DHTML Frames
Six visible frames:
Participation
Status
Frame
CoWebBrowse.htm
Chat Frame 1
URL Frame
Logoff Frame
Cobrowse Frame
Chat Frame 2
Two hidden Frames:
Pushlet frame: communicates with pushlet servlet
Postlet frame: communicates with postlet servlet
5/23/2016
28
CoWebBROWSE Prototype:
Expanding JavaScript Privileges
5/23/2016
JavaScript DOM model only allows same domain frames to
interact
Netscape’s JavaScript signing technology can expand this
interaction
Netscape’s ‘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
29
CoWebBROWSE Prototype:
Why Expanded Privileges
CoWebBrowse.htm
@
Sanluis.uccs.edu
www.cnn.com
Link:
http://www.cnn1.com
1.
User clicks on link
2.
Browser retrieves www.cnn1.com and displays
in coBrowse frame
3.
CoWebBrowse.html gets ‘onload’ event that
coBrowse frame reloaded
4.
CoWebBrowse.htm needs to ask browser for
coBrowse frame’s new URL in order to send it
to server
5.
ISSUE: JavaScript security prevents the
interaction
5/23/2016
30
CoWebBROWSE Prototype:
Expanded Privileges (Example)
function displayLocation()
{
netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowse
rRead");
var loc = frames['browseSpace'].location.href;
}
<frame src =
http://sanluis.uccs.edu:8289/CoWebBrowseProj/html/signdir/BrowsingFrame.
html name = "browseSpace" onload="displayLocation()" />
</frameset>
5/23/2016
31
CoWebBROWSE Prototype:
Load 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
5/23/2016
32
CoWebBROWSE Prototype:
Client-Server Implementation
Servlet
AcceptFromLevel2
+doGet( *:*):void
creates
Servlet
Event
uses
creates
Postlet
uses
PushletSubscriber
+doGet(*:*) :void
uses
uses
+init(*:*) :void
+processEvents():void
+send(event :Event ):void
+doHistory() :void
uses
*
uses
creates
Publisher
-subscribers:ArrayList
-groups :HashTable
+join(*:*) :void
+publish(Event :event ):void
+updateBalancer( load:String) :void
Pushlet
Singleton
-request:HttpServletRequest
-response:HttpServletResponse
+doGet(*:*):void
Adapter
Servlet
+push(Event :event ):void
BlockingQueue
SendToLevel2
+enQueue(event :event ):void
+deQueue() :Event
5/23/2016
33
CoWebBROWSE Prototype:
Session-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
5/23/2016
34
CoWebBROWSE Advantages (1)
Ubiquitous Access:
Uses trusted client technology:
5/23/2016
JavaScript, regular browser, no installations, no mobile code,
no cookies, no pop-ups
Uses HTTP(S), ports 80 and 443.
Uses Netscape’s signed JavaScript technology to expand
client privileges
Client is platform-independent
35
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:
5/23/2016
Hierarchical client-server model is highly scalable
There are multiple roots in hierarchy for improved robustness
Load balancing algorithm improves scalability and robustness
36
Key Technical Challenges
Use of signed JavaScript:
Limited documentation as a result of low penetration
Not working with new version of Mozilla (1.7)
Tomcat’s support for pushlets:
Tomcat limits the number of simultaneous servlet
connections to 10
5/23/2016
37
Performance Evaluation
Legend:
Directory Server
Database
Client Servers
Session Server
Clients
Crestone
Tomcat v5.0.18
Linux RHAT rls9
Client Mozilla 1.5 on
WinXP
HTTP
Shavano
Sanluis
HTTP Postlets
Sanluis
MySQL
JDBC
Blanca
HTTP
Wetterhorn
HTTP Pushlets
HTTP
Mozilla Version 1.5 For Windows
5/23/2016
38
CoWebBROWSE Testing
Testing included the use of chat messaging
Compared time deltas between messages entering a clientserver postlet and exiting a client-server pushlet
Averaged the results of six test executions
Timing measurements tabulated for:
5/23/2016
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
39
CoWebBROWSE Test Results
1 Client Server
20
2 Client Servers
18
3 Client Servers
Time (ms)
16
14
25
12
20
10
Time (ms)
8
15
6
10
4
5
2
0
20
18
16
14
12
10
8
6
4
2
0
0
Number Of Client Users
Number of Users vs. Client-Servers
5/23/2016
Minimum Wait Time
Average Wait Time
Maximum Wait Time
1
2
3
Number of Client Servers
User Wait Times Vs. Number Of Client
Servers (7 Clients)
40
Compatibility Test Results
Co-Browse
PowerPoint document integrated in Web Page
NO
Word document integrated in Web Page
YES
Adobe Acrobat document integrated in Web Page
NO
Web Page with multiple frames
YES
Web Page containing script that opens a new
browser window
NO
Web Page that contains dynamic content based on
time or usage
Limited usage*
Web Page that determines content based on cookies
Limited Usage*
Web page accessed over SSL
YES
*Co-Browse works, but part of page content may be different for each client
5/23/2016
41
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)
5/23/2016
42
Future Enhancements
Investigate why Tomcat only supports 10 concurrent connects
Investigate why latest version of Mozilla doesn’t 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
5/23/2016
43