Application Layer Protocols

HTTP
HTTPS (SSL/TLS)
FTP and SMTP
Email

HTTP

HyperText Transfer Protocol
request and reply headers, both encoded in ASCII (no binary)
headers are variable length, with variable fields
first line is required, some fields are required
header ends at first empty line
ancestry: FTP
HTTP/1.1 allows multiple requests/replies to be sent on a single TCP connection
in-class exercise: explain why this is an improvement over HTTP/1.0 (one request/reply per TCP connection)

HTTP example

an HTTP request might look like this:

GET /~esb/ HTTP/1.1
Host: www2.ics.hawaii.edu
Accept: */*
Connection: close

a corresponding HTTP reply might look like this:

HTTP/1.1 200 OK
Date: Thu, 19 Nov 2009 05:18:56 GMT
Server: Apache
Last-Modified: Wed, 02 Sep 2009 03:17:30 GMT
ETag: "19abf-2095-4728fb5090680"
Accept-Ranges: bytes
Content-Length: 8341
Connection: close
Content-Type: text/html

<html>
...

HTTPS

secure version of HTTP
two types of protection:
- authentication, to provide evidence that communication is occurring with the intended party (as identified by the URL)
- encryption, to hide the contents of the communication (including passwords and credit card numbers) from eavesdroppers
HTTPS is very similar to HTTP, except: SSL or TLS is used as an end-to-end secure tunnel (VPN) to connect the browser to the server (see RFC)
Transport Layer Security, or TLS (RFC 5246) provides authentication and secrecy using public-key cryptography to agree on a shared secret key
this shared secret key is then used to encrypt the data

HTTPS authentication

any public-key cryptosystem depends, for security, on knowing the other party's public key
otherwise, man-in-the-middle attacks can easily succeed
in https, the authenticity of a server's public key (correspondence between a public key and an IP+port number combination) is guaranteed by having the public key signed by a certificate authority (CA)
most web browsers are pre-configured with the public keys of multiple certificate authorities, assumed trustworthy
e.g. in firefox, Preferences->Advanced->View Certificates->Authorities
so the communication is safe as long as the certificate authority can be trusted
servers usually authenticate clients in other ways, e.g. with a password or a credit card number

Active Web

the static has been, and continues to be, was immensely successful as a repository of static information (of varying reliability)
however, the user interaction model of the static web is limited to users clicking links
for many purposes (including logging in), this is not adequate
so the web evolved to provide support for server-side and client-side code execution that could provide different models of interactivity and customization
this code generally increases the vulnerability to attack of both the client and the server
client-side code might make further requests from the server, either using HTTP or HTTPS, or a custom protocol
cookies allow the server to store state on the client, for purposes of later authentication or identity matching

FTP and SMTP

HTTP was loosely based on the model provided by the File Transfer Protocol and the Simple Mail Transfer Protocol: text-based commands to control data transfers
SMTP uses a single connection, and requires all messages to be in printable characters only, with a special escape to indicate the end of a message
FTP uses a separate connection to transfer each file, as well as a control connection for sending commands and status
HTTP/0.9 and HTTP/1.0 used a single connection per transfer, with all control information sent at the beginning of the transmission, and the end of the content marked by closing the connection
both FTP and SMTP use numeric response/error codes
both FTP and SMTP can be run over encrypted, secure connections (but aren't by default)

Email Protocols

SMTP, POP, IMAP, WebMail
SMTP is used to transmit email messages (push model)
POP and IMAP are used to receive (pull model) and manage email messages
an email message transfer is basically a file transfer, similar to an HTTP GET or PUT
although it is conventional to refer to email clients and email servers, the communication matches neither the client-server nor the peer-to-peer model:
- sending program (mail "client") gives the message to a mail transfer agent (MTA)
- MTA contacts destination mail server and delivers the message
- sometime later, mail "client" contacts mail server connected with user's account, to receive messages
- an MTA may relay through another MTA rather than directly to the destination server (system common in the pre-internet days)
some of these protocols provide encryption, e.g. POP3 and IMAP
there is generally no encryption on the MTA-to-mail-server transfer

Undesired Email

"Spam"
the cost to transmit an email is very small
the incentive to be selective in choosing the recipients of an email is not always large: reputation and stability of one's Internet connection
the cost to ignore an undesired email is small, but can add up if lots of spam is received
among these costs is the possibility of accidentally discarding desirable email
some spammer tactics:
- send emails from a commandeered machine (a "bot")
- use open relays (getting more difficult)
- use incorrect sender addresses in the mail header (easy to lie, easy to detect)
- use an ISP that is complicit
- have permissive laws
some issues (for discussion):
- can all undesired email be classified as spam?
- how should free speech be balanced against reasonable restrictions?
- do spam filters work?
- would taxing email create more problems or solve more problems?