Advanced Web Topics: Dynamic Web Technologies - PowerPoint PPT Presentation

1 / 49
About This Presentation

Advanced Web Topics: Dynamic Web Technologies


The Internet: Technology and Applications: Class #9. 1. Advanced Web Topics: ... solutions requiring dynamic web technologies -- Online banking -- Stock ... – PowerPoint PPT presentation

Number of Views:2648
Avg rating:3.0/5.0
Slides: 50
Provided by: Audrey92


Transcript and Presenter's Notes

Title: Advanced Web Topics: Dynamic Web Technologies

Advanced Web TopicsDynamic Web Technologies
Security635.413.31 Summer 2007
Introduction to Dynamic Web Technologies
  • The need for dynamic content
  • The basic model of the web, with static delivery
    of content, hampers the deployment of advanced
  • Instead of rewriting HTML and HTTP, dynamic web
    content has been added through the use of
    helper programs and protocols
  • While XML promises to address the problem, the
    Web will be based primarily on HTML, HTTP
    helper programs for a long time to come
  • Examples of solutions requiring dynamic web
  • -- Online banking -- Stock Trading
  • -- Online auctions -- Almost any variety of
  • Disadvantages of dynamic content (compared to
    basic static content)
  • Programming expertise required
  • Increased computing requirements
  • More difficult to test and debug
  • Security issues

Server-side Technologies
  • There are two major means of providing dynamic
    web content
  • Client-side technologies and Server-side
  • Introduction to Server-side Technologies
  • All dynamic processing done on or behind the
    web server
  • A new HTML document is created for each request
    depending on a number of parameters associated
    with the request (and their corresponding values)
    the document created could be different
  • The client (browser) knows nothing of the dynamic
    content all it deals with are static HTML pages
  • Advantages
  • Gives the Web the ability to report current
  • Easier control of content by the creator
  • Imposes no special requirements on the client
    (browser) or the hardware and software it runs on

Server-side Technologies
  • Introduction to server-side technologies
  • Disadvantages
  • Increased cost (compared to static content)
  • Increased network traffic
  • Increased server load and processing requirements
  • Inability to easily update real-time or NRT
  • Examples of server-side technologies
  • The common gateway interface (CGI)
  • Active server pages (ASP) now ASP.NET
  • PHP

Client-Side Technologies
  • Introduction
  • Information and some flavor of executable code is
    downloaded from the server to the client
    (browser) to run
  • All processing of information is done by the
    client (browser)
  • The document is never fully specified by the
    server Content display depends on processing
    done by the client
  • Advantages
  • Ability to update information in near real-time
    or better
  • Allows much more sophisticated functionality
    (animation, etc.) that is difficult or impossible
    with other approaches
  • Much more flexible than static or server-side
    dynamic technologies

Client-Side Technologies
  • Introduction (continued)
  • Disadvantages
  • Imposes special hardware, software, and browser
    requirements because of all the local processing
    necessary to display the information
  • Creates many security concerns associated with
    the downloading of executable code
  • Many dynamic client-side technologies allow the
    downloaded code to communicate across the network
    to send or gather information
  • Many times the downloaded code can create,
    modify, and delete files on the client system
  • More difficult to create (program), test, and
    debug client-side dynamic code because of
    variations in client hardware and software
  • Examples of Client-Side Technologies
  • Java
  • Javascript
  • ActiveX

The Common Gateway Interface
  • Two Server-side Dynamic Web Technologies in
    depth CGI ASP
  • Introduction to the Common Gateway Interface
  • A standard developed by the folks at NCSA to
    allow external information sources to be
    dynamically accessed and displayed via a web
  • The current specification is CGI version 1.1 --
    version 1.2 is currently in development (as well
    as other enhanced variants)
  • CGI allows external applications to be called by
    a web server and have the output from the
    application directed back to the server

The Common Gateway Interface
  • CGI Implementation
  • CGI programs reside in a special directory
    (typically cgi-bin) this is where the web
    server process looks for the CGI program when it
    encounters a URL containing a CGI script
  • CGI scripts can be written in a variety of
    languages including
  • Perl
  • TCL/TK
  • C/C
  • Visual Basic
  • AppleScript
  • Any Unix shell scripting language
  • With many web servers CGI support is built in and
    automatically activated with others the web
    server has to be explicitly configured to support
    CGI programs

The Common Gateway Interface
  • Input to a CGI program
  • Input to a CGI program can come from both the web
    browser and the web server passing the call to
    the CGI program
  • Client Input
  • Very important for many dynamic web based
  • Input is typically through the use of HTML Forms
  • Input can be sent back from the client (browser)
    in two ways
  • Method 1 Using the HTTP GET command
  • Client information is embedded directly in the
    URL sent to the server
  • Client information is found in the ltquerygt part
    of the URI/URL separated from the rest of the
    URI/URL by a question mark
  • Example URL with user information

The Common Gateway Interface
  • Form example
  • ltFORM ACTIONhttp//
  • Name ltINPUT NAMEcustomer SIZE30gtltPgt
  • Street Address ltINPUT NAMEAddress
  • City ltINPUT NAMECity SIZE20gtltPgt
  • StateltINPUT NAMEState SIZE2gtltPgt
  • Zip Code ltINPUT NAMEZip SIZE5gtltPgt
  • ltINPUT TYPESUBMIT VALUESubmit InfogtltPgt
  • lt/FORMgt
  • What URL would be created from this
  • http//
  • DoeWayCityColumbiaStateMDZip21046

The Common Gateway Interface
  • Method 2 Using the HTTP POST command
  • Client information is sent back in the body of
    the HTML page generated by the POST command
  • Syntax of the client information is the same as
    the query part of the URL in the GET command
  • Client information sent back to the server in
    either way is handed to the CGI program using the
    QUERY_STRING environment variable
  • Web Server Input
  • Besides the information from the client there are
    several other environment variables set by the
    web server that can be used by the CGI program
  • Like the client information the web server
    information can be used to influence execution of
    the CGI program and/or output of results
  • Example Web Server environment variables
  • REMOTE_ADDR IP address of the client (browser)
  • REQUEST_METHOD How the CGI program was called
    (usually equals GET)
  • HTTP_USER_AGENT specific client info (e.g --
    Mozilla/4.61 en Win NT)

The Common Gateway Interface
  • State information
  • To create a better user experience there are
    times when it is advantageous for state
    information to be collected about clients and
  • Since web servers do not typically store state
    information it falls to the CGI program to
    maintain state information
  • Two ways a CGI program can maintain state
    information long-term and short-term
  • Long-Term state information
  • Information is stored on the server by the CGI
    program in a variable or file created by the
  • Variables persist as long as the CGI program is
    running files can persist across restarts of the
    web server

The Common Gateway Interface
  • State information (continued)
  • Short-Term state information
  • For information that does not need to be stored
    longer than the browser is running
  • State information is embedded in the URL passed
    back and forth between the client (browser) and
    the CGI program
  • Note that the CGI program doesnt really know
    whether the state information is correct or not
    it is merely manipulating the state information
    sent to it by the client

The Common Gateway Interface
  • Example CGI script (Outputs the current CGI
    environment variables)
  • !/bin/sh
  • An example script that echoes environment
    variables back to the client for display
  • echo Content-type text/plain
  • echo CGI/1.0 test script report
  • echo argc is . argv is "".

Active Server Pages (ASP)
  • Introduction
  • Developed by Microsoft to provide better
    functionality and resource utilization than CGI
  • CGI programs typically load a new process for
    each request this is very resource intensive
  • ASP uses a memory resident DLL for all requests
    for efficiency
  • Proprietary to Microsoft ASP found only on
    servers running MS Internet Information Server
  • ASP is actually a special part of a Microsoft API
    toolkit called ISAPI (Internet Services API)

Active Server Pages (ASP)
  • ASP Operational Overview
  • Client (browser) calls ASP web page (denoted by a
    page request using a URL ending in .asp)
  • IIS sees GET command contains a URL ending in
    .asp and redirects it to ASP.DLL
  • ASP.DLL parses command and calls the appropriate
    DLLs necessary to handle the request
  • Output (if any) is passed back to ASP.DLL
  • ASP.DLL passes output to IIS
  • IIS sends generated page back to client (browser)

Active Server Pages (ASP)
  • ASP Object Model
  • ASP has an object oriented structure with typical
    properties such as encapsulation and inheritance
  • Six fundamental objects are defined
  • Application contains methods (events) and data
    related to the initialization and termination of
    your application
  • ObjectContext used exclusively for support of
    MS Transaction Server
  • Request The primary input object
  • Receives data input from client or IIS used to
    run the ASP program
  • Analogous to the CGI environment variables
  • Response The primary output object
  • Used to send data back to the client
  • Contains variables and methods for other
    functions such as cache control and cookies
  • Server contains methods and variables used for
    communication with IIS
  • Session contains methods and data specific to
    the current session

Active Server Pages (ASP)
  • An example ASP program (time.asp)
  • ltHTMLgtltHEADgtltTITLEgt ASP Example lt/TITLEgtlt/HEADgt
  • ltBODYgt
  • lt
  • This is a comment within the asp code
  • The lt gt tags delimit the asp code
  • strGreetingMsg Hello. It is now Time() _
    on the server.
  • Response.Write strGreetingMsg
  • gt
  • lt/BODYgtlt/HTMLgt
  • Generated Output (as a web page)
  • Hello. It is now 124701 on the server.

  • Java is an example of a client-side dynamic web
  • Introduction
  • Java is a specific programming environment
    developed by Sun Microsystems to allow the design
    of client-side dynamic web pages
  • The Java programming environment was designed to
    make Java operation independent of the underlying
    software and hardware
  • In the past several years Java has become one of
    the most important dynamic web technologies
    almost all web browsers released in the past four
    years support Java
  • Microsoft has developed its own version of Java
    usually called J there are still some
    compatibility issues and legal arguments over
    Javas future
  • In a sense Java has been developed from C
    however it has been streamlined to eliminate most
    of the least used easily misunderstood features

  • The Java Programming Environment has three major
  • The Java Run-Time Environment
  • The Java Language
  • The Java Class Library
  • Java defines a Run-Time Environment or virtual
    machine in which Java Programs actually execute
    on the client (browser)
  • Java programs are converted from source code to
    machine executable code in a two step process
  • Step one involves the developer compiling the
    source code into an intermediate,
    system-independent format called Java Bytecode
  • In step two the bytecode is downloaded to a
    client browser the Java Runtime Environment
    interprets it into local system executable code
  • This two-step process makes Java a write-once,
    run-anywhere language
  • Ensures any system can run the Java applet
    reduces development cost
  • It also helps ensure the graphics output will be
    the same on all systems

  • Important functionality of the Java Run-Time
  • Multi-threaded execution handles Java thread
    scheduling and context switching
  • Automatic Garbage Collection minimizes memory
    leaks and simplifies programming tasks
  • Internet Access includes a socket library for
    transport layer TCP or UDP access
  • Extensive Graphics Support includes an
    extensive set tools for both low-level and
    high-level control of the client graphics
  • The Java graphics toolkit is called the Abstract
    Window Toolkit (AWT)
  • The high level functionality allows a developer
    to work with an already defined generic
    rectangular window complete with title, borders,
    and scroll bars
  • The low level functionality gives a developer
    complete control over the size, shape, color, and
    other features of the window (at the expense of a
    lot more work)

  • Java Language Characteristics
  • High Level provides a high level of abstraction
    and hides details of the underlying hardware if
    the programmer does not wish to deal with them
  • General Purpose can be used for more than
    writing web-based applets
  • Object Oriented conforms to the common
    definitions of an object oriented programming
  • Dynamic Object instances are created
    dynamically at run-time
  • Strongly Typed operations (methods) defined for
    a certain data type can only be used on that data
  • Statically Type Checked type checking done when
    the source code is compiled into bytecode
  • Concurrent Execution allows multiple threads to
    execute simultaneously

  • The Java Class Library
  • The Java Class Library contains an extensive
    variety of classes for all aspects of system
  • Examples of Kinds of Classes defined in the
  • Graphics Support
  • Network Input/Output
  • Web Server Communication
  • Java Run-Time Environment System Access
  • File Input/Output
  • Common Data Structures
  • Event Capture
  • Exception Handling

  • Compiling the Applet
  • The compiler for Java is usually called javac
  • Javac takes the source code file (which has to be
    named .java), verifies the proper syntax of the
    source code, translates it into bytecode, and
    places the output in a file named .class
  • The source file must contain at least one public
    class and this one class has to have the same
    name as the file that contains it.
  • The link between Java and HTML
  • Applets can be run directly by plugging its URL
    into the web browser but typically the link to an
    applet is embedded into an HTML document

  • The APPLET tag
  • The APPLET tag is used to embed a link to the
    Java applet into a HTML document
  • Two attributes are required in the APPLET tag to
    run the Java applet
  • The CODEBASE attribute specifies the system and
    path to the Java applet
  • The CODE attribute specifies the name of the Java
  • Example ltAPPLET
  • The closing lt/APPLETgt is required even though in
    most cases it does not seem to be necessary

  • An example Applet (A colorbox on the screen)
  • Import java.awt.
  • Import java.applet.Applet
  • / Example displays a filled colored box in the
    browser window /
  • public class FilledBox extends Applet
  • Color boxColor
  • // called only once when applet is initialized
  • public void init()
  • String s
  • s getParameter(color)
  • // the default color is gray
  • boxColor Color.gray
  • if ( s ! null)
  • if (s.equals(white)) boxColor Color.white
  • if (s.equals(blue)) boxColor
  • if (s.equals(red)) boxColor
  • // this is called whenever the browser needs to
    redraw the applet
  • public void paint(Graphics g)

  • An example Applet (Continued)
  • Example call from HTML page
  • ltAPPLET CODEBASE/users/smiley
    CODEFilledBox.class WIDTH200 HEIGHT60gt
  • ltPARAM NAMEcolor VALUEbluegt
  • lt/APPLETgt

  • Javascript another client-side dynamic web
  • Introduction
  • Javascript was designed to provide a quick and
    easy way to gain the leverage the benefits of
    Java for small, simple applications
  • Javascript is embedded right in the HTML source
    code for easy integration with web pages
  • Javascript is supported on Netscape Navigator 4.x
    and IE 4.x and later versions there are minor
    compatibility issues between Netscape and MS
  • ECMA has standardized Javascript but their
    published standard is slightly different than
    both the Netscape and Microsoft implementations
    (ECMA European Computer Manufacturers

  • Javascript Advantages
  • Small and simple to use
  • Quick to learn
  • Can be developed using HTML tools no separate
    compiler and development environment necessary
  • Javascript Disadvantages
  • Speed Javascript source code can take longer to
    download than Java bytecode
  • Scalability compared to Java, Javascript is
    very limited in its functionality
  • Not compatible with earlier versions of browsers
    that do not have Javascript functionality
  • Harder to guarantee interoperability with clients

  • Javascript functionality syntax is similar to
    Java but much more limited in scope
  • With respect to Java, Javascript is restricted
    from the following
  • Access only to information from (or on) its
    uploaded HTML page
  • No access to client browser history file
  • No file uploads, use of e-mail, or posting of
    news articles
  • Can only close windows it has created
  • Cannot read or set client browser preferences
  • Javascript does not use bytecode source code is
    downloaded directly (in the web page) and
    interpreted in the client browser
  • Javascript is usually embedded into the HTML page
    using the ltSCRIPTgt and lt/SCRIPTgt tags
  • It can also be used in an event handler routine
    (example ltINPUT TYPEButton VALUEPress Me
  • It can also be used in a URL the Javascript is
    executed and the value is inserted in the URL
    (example validating input before it is sent
    back to the server as CGI data input)

  • Javascript Example
  • Plenty of others on Internet (e.g. stock
    calculator) look at http//
  • What goes into the header of the HTML Page
  • ltHEADgt
  • ltSCRIPT LANGUAGE"JavaScript"gt
  • lt!Example JavaScript This causes a description
    to show up when you mouseover a hyperlinked
  • lt!-- Begin
  • function showMsg(text)
  • document.picform.message.value text
  • // End --gt
  • lt/scriptgt
  • lt/HEADgt

  • (Example Continued) What is in the body of the
    HTML Page
  • ltBODYgtltCENTERgt
  • ltulgtltligt
  • lta href"HTTP//WWW.SITE1.COM"
    onmouseover"showMsg('this is information about
    pic 1....')"
  • onmouseout"showMsg('')"gt
  • ltimg name"button1" src"HTTP//WWW.YOUR-SITE.COM/
  • lt/ligtltligt
  • lta href"HTTP//WWW.SITE2.COM"
    onmouseover"showMsg('this is information about
    pic 2....')"
  • onmouseout"showMsg('')"gt
  • ltimg name"button2" src"HTTP//WWW.YOUR-SITE.COM/
  • lt/ligtltligt
  • lta href"HTTP//WWW.SITE3.COM"
    onmouseover"showMsg('this is information about
    pic 3....')"
  • onmouseout"showMsg('')"gt
  • ltimg name"button3" src"HTTP//WWW.YOUR-SITE.COM/
  • lt/ligt
  • ltform name"picform"gt
  • lttextarea namemessage rows2 cols40
    wrapvirtualgtchoose an image for a
  • ltinput typehidden namego value""gt

Web Services
  • The Web as a Content Delivery Vehicle
  • In recent years the WWW has moved from an
    end-user oriented data delivery system to a
    complete service-oriented architecture
  • Enables new B2B (Business-to-Business)
    capabilities potentially other far-reaching
  • Four core components to Web Services
  • XML
  • SOAP (Simple Object Access Protocol)
  • WSDL (Web Services Description Language)
  • UDDI (Universal Description, Discovery,
    Integration) protocol
  • There are plenty of other standards developed by
    the W3C and OASIS for Web Services

Web Services
  • The Simple Object Access Protocol (SOAP)
  • Used to exchange structured typed messages
    between peers
  • Standards defined by the W3C current version is
  • SOAP components/messages written in XML
  • Basic Communications Attributes
  • Usually carried in HTTP, but other transport
    mechanisms can be specified (e.g. SMTP)
  • Provides a stateless one-way message passing
  • More complex functions can be assembled from the
    basic operation
  • Provisions for basic error handling, but the
    specifics must be specified to match underlying
    transport protocol
  • SOAP Message Structure
  • Envelope encloses entire SOAP message
  • Header optional component inside envelope
  • Body mandatory component inside envelope

Web Services
  • Example Simple Object Access Protocol (SOAP)
  • lt?xml version'1.0' ?gt
  • ltenvEnvelope xmlnsenv"http//
  • ltenvHeadergt
  • ltmreservation
  • xmlnsm"http//
  • envrole"http//
  • envmustUnderstand"true"gt
  • ltmreferencegtuuid093a2da1-q345-739r-ba5d-pqff
  • ltmdateAndTimegt2001-11-29T133650.000-0500lt/
  • lt/mreservationgt
  • ltnpassenger xmlnsn"http//mycompany.example.c
  • envrole"http//
  • envmustUnderstand"true"gt
  • ltnnamegtÅke Jógvan Øyvindlt/nnamegt
  • lt/npassengergt
  • lt/envHeadergt
  • ltenvBodygt
  • ltpitinerary

Web Services
  • The Web Services Description Language (WSDL)
  • Used as a structured, standardized means of
    describing a web service
  • Standards defined by the W3C current version is
  • WSDL documents written in XML
  • Basic parts of a WSDL defined Web Service
  • Interface(s)
  • Operations, Messages, Message Exchange Protocol
  • Elements of service
  • Binding of Service (i.e. turns abstract
    operations/messages interface(s) into
    implementable specifics msgs. use SOAP 1.2 and
    HTTP 1.1)
  • Service Definition (specifically where the
    service can be accessed)

Web Services
  • Example WSDL Specification (Service Portion)
  • lt?xml version"1.0" encoding"utf-8" ?gt
  • ltdescription
  • xmlns"http//"
  • targetNamespace "http//
  • xmlnstns "http//
  • xmlnsghns "http//
  • . . .
  • xmlnswsdlx"http//
    ons"gt . . .
  • lttypesgt
  • ...
  • lt/typesgt
  • ltinterface name "reservationInterface" gt
  • ltfault name "invalidDataFault"
  • element "ghnsinvalidDataError"/gt
  • ltoperation name"opCheckAvailability"
  • pattern"http//
  • style"http//
  • wsdlxsafe "true"gt

Web Services
  • The Universal Discovery, Description
    Integration (UDDI) protocol
  • Designed to provide an open, vendor-neutral
    framework for advertising and finding web
  • Supports different service description types,
    though WSDL is the recommended method of
  • UDDI messages (commands/responses) sent in SOAP,
    usually over HTTP
  • Messages must be encoded in the registrys schema
  • UDDI registries designed to provide three basic
  • White Pages businesses by name
  • Yellow Pages businesses by category
  • Green Pages registration/searching of
    businesses services
  • Primary UDDI Data Structures
  • BusinessEntity information on a business
  • BusinessService info on a service provided by a
  • bindingTemplate tech info needed to access a
    specific service
  • tModel_Structure provides extra info allowing
    better discovery of services
  • Publisher allows modeling of more complex
    businesses (e.g. large company with
    semi-independent subsidiaries)

Web Services
  • How it all fits together for B2B Web Service

The World Wide Web and Security
  • Introduction
  • There is a need for security on the World Wide
    Web because theres no security mechanisms built
    into the basic web protocols
  • No authentication
  • No data integrity (from an application
  • No privacy
  • This clearly limits the usefulness of the WWW for
    many future applications
  • To deploy these applications a secure web-based
    infrastructure must be developed that provides
    the four fundamental security services
  • authentication
  • non-repudiation
  • data integrity
  • privacy
  • So far two different protocols have been
    deployed The Secure Sockets Layer (SSL) and
    Secure HTTP (S-HTTP)

The Secure Sockets Layer (SSL)
  • Introduction
  • SSL provides a secure communications channel with
    the ability to implement the four fundamental
    security services
  • SSL was originally developed by Netscape to
    provide secure communications between their web
    servers and browsers
  • SSL sits between the application and the
    transport layers it is not limited to use with
    HTTP but can and will be used for other
    applications requiring security (such as Secure
    Telnet general VPN service)
  • Netscape openly published the SSL specification
    and it has been universally adopted by other web
    server and browser developers
  • Latest version is 3.0 the IETF has developed a
    successor to SSL called Transaction Layer
    Security (TLS v1.1 is defined in RFC 4346 and is
    based on SSLv3)
  • SSL must run over a reliable transport layer
    protocol in the TCP/IP world it must use TCP
    (typically on port 443)

SSL Implementation
  • SSL Implementation Details
  • SSL sessions are usually initiated by accessing a
    URL that contains
  • https// as its protocol part
  • SSL actually provides symmetric security
    services two-way authentication and
    non-repudiation can be used if it is really
    necessary to verify the server
  • SSL can use a variety of digital certificates
    (X.509 or Fortezza) as well as a variety of
    private and public key encryption algorithms
    (RSA, DES, etc.)
  • SSL consists of two layers (or more
    appropriately sub-layers)
  • the Message Layer
  • the Record Layer

SSL Implementation
  • The Message Layer
  • The upper SSL layer that interfaces to the
    application layer
  • Responsible for exchanging information with the
    application layer
  • SSL Message Layer entities exchange four
    different types of messages User Data (from the
    application layer), Alerts, ChangeCipherSpecs,
    and Handshake Messages
  • User Data Messages are the same size as the
    application reads and writes
  • Alert Message carry error information and
    responses (handshake failure, bad certificate,
  • ChangeCipherSpec Messages allow the applications
    to change security parameters (encryption key
    length, algorithm, etc.)
  • Handshake Messages are used to initiate an SSL

SSL Implementation
  • The Record Layer
  • The lower SSL layer that interfaces to the
    reliable transport layer
  • Transfers blocks of streamed data (called
    records) containing up to 16,383 bytes of
    payload (from the Message layer)
  • Multiple SSL messages could be combined into a
    single record or a large SSL message could be
    broken into multiple messages (hence the transfer
    of streamed data)
  • A record also contains a header specifying the
    content type, SSL protocol version, record
    length, and a Message Authentication Code (MAC)
  • The use of a unique sequence number and the MAC
    at the record layer provides data integrity

SSL Implementation
  • SSL in action initiation of a secure web
  • The SSL Handshake consists of a 12 message
    sequence some are optional and are only used
    when required by the parameters agreed upon for
    the session.
  • Client opens connection sends SSL ClientHello
  • Server sends SSL ServerHello Message
  • Server sends SSL Digital Certificate Optional
    for 2-way authentication
  • Server sends SSL ServerKeyExchange Optional
    for sending additional encryption
    authentication parameters
  • Server sends SSL CertificateRequest Optional
    for authenticating the client
  • Client sends SSL Digital Certificate Optional
    in request to previous message
  • Client sends SSL ClientKeyExchange Contains
    agreed-upon session parameters
  • Client sends SSL ClientVerify contains hash
    values for all previous handshake messages if
    they dont match the values calculated by the
    server session is aborted
  • Client AND Server both send ChangeCipherSpec
    Messages sends encryption keys to use for the
    remainder of the session
  • Client AND Server both send Finished Messages
  • Once the handshake is complete secure application
    layer data can be transferred

Secure HTTP (S-HTTP)
  • Introduction
  • Another approach to security web/http exchanges
  • Instead of providing a generic security layer
    between transport and application layer entities
    S-HTTP provides a secure transport layer
    specifically for HTTP transfers.
  • Like SSL, S-HTTP provides the four fundamental
    security services for web transactions
    authentication, non-repudiation, data integrity,
    and privacy
  • S-HTTP can work with a variety of digital
    certificate types, encryption algorithms, and
    authentication methods
  • S-HTTP is an IETF experimental standard published
    in RFC 2660
  • In my experience, S-HTTP implementation has been
    much more limited than SSL and at this point is
    rarely found in use (though it does provide a
    good study of another way to secure web content)

S-HTTP Implementation
  • S-HTTP augments the normal HTTP procedures, using
    additional MIME-like security headers to send and
    negotiate security information
  • The secure HTTP requests and replies are
    actually encapsulated inside S-HTTP requests and

S-HTTP Message Secure Secure-HTTP/1.4 Content-Ty
pe message/http Prearranged key-info
des-cbc,abc12, inband1 Content-Privacy-Domain
HTTP Message HTTP / 1.0 200 OK Header
text/html HTML Header Body
S-HTTP in action an example session
  • Client -gt Server Requests normal HTTP page with
    an S-HTTP link in an anchor tag on the page (such
    as ltA HREFshttp//www.secret.comgt this is secret
  • Server -gt Client Sends web page with the S-HTTP
    link embedded on the page along with security
    information (in the page header) for accessing
    the link (public key, encryption method, etc.)
  • Client -gt Server If the user clicks on the
    S-HTTP link, the following happens
  • A HTTP Request is generated for the page
  • Using the security parameters sent by the server
    the HTTP Request is encapsulated in a S-HTTP
  • S-HTTP message sent to the client the payload
    may be encrypted if that service was specified in
    the security parameters
  • Server reconstructs HTTP using the instructions
    received in the S-HTTP envelope
  • Server -gt Client Using the received client
    request, server retrieves page to send
  • Web page and HTTP header fields are encapsulated
    in a S-HTTP envelope
  • S-HTTP message sent to the client the payload
    may be encrypted if that service was specified in
    the service parameters

Reading Homework
  • Reading
  • Only Section 31.12 (SSL/TLS) reference RFCs for
    any details needed
  • Homework 5 (due Thursday 7/15)
  • Chapter 27 27.7 and 27.11
  • Chapter 29 29.1, 29.3, and 29.9
  • (25) Research TLS and explain what enhancements
    TLS has over SSL. Use a packet sniffer (e.g.
    Ethereal) to examine a secured (e.g. https//)
    connection to a web server. Analyze report on
    the details of it.
  • (25) Research Web Services and write a short (1
    page) synopsis on what standards have or are
    being developed for securing such services. Make
    sure to provide at least a basic technical
    description of the service(s) discussed cite
    your references.
  • (25) Find an example of proprietary SNMP MIB
    that has been defined explain what vendors make
    model equipment the MIB is for, what
    functionality it provides, and try to explain why
    the vendor went to the effort to define a special
  • Problems worth 25 of HW grade
Write a Comment
User Comments (0)