HTTP Basics

HTTP messages

  • HTTP messages are requests sent from clients to servers, and responses from servers to clients
  • HTTP message structure
    • start line
    • 0 or more headers, each header contains field name, colon, field value
    • optional message body
  • HTTP request
    • start line: request method
      • GET
      • HEAD
      • POST
      • PUT
      • DELETE
  • HTTP response
    • start line: status line, contains
      • HTTP version used by the server
      • status code
        • 200 -> ok
        • 404 -> not found
        • 401 -> unauthorized
        • 403 -> forbidden
      • reason phrase

HTTP cache security issues

  • a cache is a local store which may be created and maintained by a client, a proxy or a gateway
  • cache control can be implemented by setting in header “cache-control”
  • sensitive information may be cached, e.g. password and payment receipt
  • dishonest proxy may cache “everything”

HTTP Authentication

HTTP basic authentication

  • mechanism
    • use username and password in a dialog
    • fail -> send 401 status code
  • problems
    • username and password are BASE64-encoded and sent with every request, which can be intercept and read (no encryption)

Form-based authentication

  • mechanism
    • use a standard HTML page to request the username and password (instead of the pop-up dialog box in HTTP basic authentication)
    • the password is sent in plain text from the client to the server
    • after a password is sent, a cookie is typically passed back-and-forth between the client and the server to indicate that the client is already authenticated: the cookie can be intercepted

HTTPS mutual authentication

  • strongest form of authentication
  • client is required to have a private key and a corresponding certificate to be authenticated
  • the server only allows clients that have a certificate that has been authorized to access the given resource
  • in order for each user to have a certificate, he should obtain one from the CA (e.g. verisign), or establish your own CA to issue certificates
  • not a popular approach

HTTP digest authentication

  • use message digest to exchange information proving that the user knows their password without sending the password itself
    • the server creates a nonce, a random value that is unique, e.g. the client IP address + timestamp + random data
    • the server sends the nonce to the client
    • the client hashes the nonce together with its username and password
    • the client sends the hash back to the server
    • the server then computes the hash with the username, password and nonce
    • the server compares the two hashes
      • if they match, the client is given access to the protected resource
      • if not match, access is denied
  • function of timestamp
    • to avoid replay attack

SSL/TLS

TLS (Transport Layer Security)

  • overview
    • a security protocol on top of TCP that replaces the widely used SSL
    • applications use TLS should be extended with the corresponding functions calls (TLS programming library)
    • TLS v1.0 developed from SSLv3
    • TLS and SSLv3 are very similar, but different enough to ensure NOT inoperable, e.g. SSL uses MD5 and TLS uses HMAC, but TLS can “back down” to SSLv3
    • TLS provides data integrity, data confidentiality, and peer entity authentication
  • TLS encrypted packet
    • TLS record protocol
      • uses for encapsulation of higher level protocols
      • takes messages to be transmitted, fragments data into manageable blocks, applies a MAC, encrypts and transmits
    • TLS handshake protocol
      • for the client and the server to authenticate each other and negotiate an encryption algorithm and cryptographic keys before the application-level data is transmitted
      • consists of the following 3 protocols
        • handshake protocol: the client and the server agree on a protocol version, select cryptographic algorithm, optionally authenticate each other, and generate shared secret key
        • change cipher protocol: a single message sent by both the client and the server to notify the receiver that the subsequent message will be protected with the agreed security parameters
        • alert protocol: various alert messages for notifying the receiver that the connection will be closed, or that an error condition has occurred
      • 3 authentication modes
        • server authentication only
        • authentication of both parties (mutual or client/server authentication)
        • total anonymity

HTTP with SSL/TLS

  • HTTP transaction
    • SSL/TLS suits HTTP since it can provide some protections if only one side of the communication is authenticated
    • HTTPS signals the browser to use an added encryption layer of SSL/TLS to protect the traffic, which provides a secure channel over an insecure network
  • trust
    • user
      • trust browser
      • trust CA
      • trust SSL/TLS protocol and it is good
    • website
      • provide a valid certificate
      • the certificate correctly identifies the website
  • HTTP procedure
    • the browser requests a document with a special URL which commences https, instead of http
    • the browser recognizes the TLS request, and establishes a connection through TCP port 443 to the TLS code on the server
    • the browser then initiates the TLS handshake phase, using the TLS record protocol as a carrier
    • following the handshake, both browser and the server have a shared secret master key
    • from the master key, both browser and the server can generate other session keys, which are used to encrypt the session data
      • the browser may use for a long time, use this mechanism to change the session key periodically
      • becasue the browser and server also trust the master key
    • the requested document is then encrypted with the session key and then the sent from the server to the client
  • limitations
    • SSL mixed content problem
      • a webpage has HTTP and HTTPS contents
      • data unprotected by SSL may be seen by intermediate routers
      • in many cases this is still safe
      • but, attack code in non-SSL data can be dangerous
    • SSL protection
      • SSL provides secure encryption in the two points (browser and server)
        • no intermediate routers or processes can see the content transmitted between the browser and the server
      • the two endpoints can still leak information
        • e.g. attack the information before the client or server’s encryption
    • heartbleed problem
      • due to OpenSSL
        • did not check for invalid user input
        • did not check for buffer over-read
      • scenario
      • an attacker can request that a running TLS server hand over a relatively large slice (up to 64KB) of its private memory space
      • this private memory space can potentially store
        • long-term server private key
        • TLS session keys
        • confidential data like passwords
        • session ticket keys

IPsec

Implementation

  • IPsec provides transport security for all users of IP, without changing the interface to IP, i.e. upper layer protocols need not be modified to invoke security and need not be aware that their traffic is protected at the IP layer
  • IPsec provides host-to-host security, but not user-to-user or application-to-application security

IP security protocol

  • network layer security
    • provides secrecy by encrypting all IP datagrams (e.g. TCP/UDP segments, ICMP messages)
    • transparent to applications above the IP layer
  • source authentication
    • able to authenticate the IP source addresses, to prevent spoofing IP addresses
  • 2 principle protocols
    • Authentication Header (AH) protocol: provides authentication and integrity for packet sources
      • not used now, because no encryption, only authentication
      • existing reason
        • in the 1990s, export restrictions on encryption algorithms required “exported” products to provide an authentication-only mechanism
    • Encapsulation Security Payload (ESP) protocol: provides authentication and integrity for packet sources, and confidentiality using AES
  • services
    • indirect access control support
    • connectionless integrity
    • data origin authentication
    • protection against replaying/reordering of IP packets
    • confidentiality
    • limited traffic flow confidentiality
  • key components
    • security protocols (AH, ESP)
    • security association (SA)
    • algorithm for authentication and encryption
    • key management (IKE)
  • modes
    • transport mode
      • protection is afforded from host-to-host and host-to-gateway
      • uses the original IP header (not encrypted): protects the packet payload
      • an upper-layer protocol frame, e.g. TCP or UDP frame, is encapsulated within the ESP
      • both hosts have to IPsec aware
    • tunnel mode
      • supports gateway-to-gateway and host-to-gateway connections, rarely used for host-to-host connection
      • uses IPsec header: protects both the original IP header and the payload, more difficult for attackers to identify targets
      • the whole IP packet is treated as a new payload of an outer IP packet, the original inner IP packet is encapsulated within the outer IP packet
      • end hosts need not be IPsec aware
  • SA (Security Association)
    • specifies the manners in which packets are protected, includes cryptographic algorithms, keys, IV, lifetimes, sequence numbers and the mode
    • before sending secured data packets from the source to the destination, the source and network hosts handshake and create a network-layer logical connection, called security association
    • for two-way communication between a sender and a receiver, 2 SAs are required
    • an SA is a 3-tuple
      • a security protocol (AH or ESP) identifier
      • the source IP address
      • a 32-bit connection identifier called the Security Parameter Index (SPI): all datagrams in the SA will have the same SPI