1 / 11

The Elbert HTTP Server

The Elbert HTTP Server. HTTP Authentication, providing security in tough times By: Shawn M. Jones. Updated FSM. Authentication FSM. Authentication: Basic. Split the Authorization header, extracting the base64-encoded secret

valiant
Download Presentation

The Elbert HTTP Server

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. The Elbert HTTP Server HTTP Authentication, providing security in tough times By: Shawn M. Jones

  2. Updated FSM

  3. Authentication FSM

  4. Authentication: Basic • Split the Authorization header, extracting the base64-encoded secret • Decode the base64-encoded secret, extract the username and password • Use MD5 to generate a one-way hash of the password supplied by the client • Use the username to find the hashed password known by the server • Compare the hashed value from #3 to #4 • If they match, return 200 • If not, return 401 with WWW-Authenticate header

  5. Authentication:Digest • Parse the Authorization header into key-value pairs • Determine if the nonce is stale, or invalid; if invalid, return 401; if valid, go on • Use the username to find the MD5-hashed secret known by the server MD5(username:realm:password), store it as A1 • Calculate A2 based on the value of qop • If qop == “auth” then A2 = “:URI” • elsifqop == “auth-int” then A2 = “:URI:MD5(entity-body)” • Create a digest using the data provided by the client, mixed with the A1 calculated form the server, of the form MD5(A1:nonce:ncount:cnonce:qop:MD5(A2)) • Compare #5 with the “response” value provided by the client • If they match, return 200 • If not, return 401 with WWW-Authenticate header

  6. Is the given nonce stale? • Extract the nonce used the client from the headers • base-64 decode it and split on whitespace to get the timestamp and the md5-hashed value of (timestamp:ETag:private-key) • use the given timestamp along with the ETag and private-key to generate an MD5-hashed value • If it is valid, continue; otherwise send a 401 • If the timestamp is not the current timestamp, the nonce is stale; send a 401 with stale=True • Otherwise, it is fresh; so continue to process

  7. Completed Work • Status 416 for bad ranges • Authentication: Basic • Parse the WeMustProtectThisHouse! File • logging the username in Common Log Format • WWW-Authenticate Header with Basic and realm • Authorization header with Basic and realm • Comparison of secret supplied by client with one known by server • 200 OK if they match • 401 if they don’t, or if no challenge was made to begin with

  8. Completed Work • Authentication: Digest • Parse the WeMustProtectThisHouse! File • logging the username in Common Log Format • Can Parse Authorization Request Header with Digest • username • realm • uri • qop • nonce • nc • opaque • cnonce • response

  9. Completed Work • Authentication: Digest • WWW-Authenticate Response header (401) • realm • domain • qop • nonce • algorithm • opaque • Authentication-Info Response header (200) • qop • rspauth • nc • cnonce • 401trumps 404 • 404 in cases where Authentication is successful, but the URI has no representation • GET/HEAD with Range header works with Authentication • 400 for malformed directives, a URI in the request line that doesn’t match the uri directive, etc.

  10. Work Remaining • Authentication: Digest • WWW-Authenticate header • stale • Authorization header • nextnonce • qop type auth-int • algorithm type MD5Sess

  11. Questions for Dr. Nelson • The client doesn’t request MD5-sess, so when does the server use it (PUT and POST?) • When does the client request auth-int, with PUT and POST? • For the domain part of WWW-Authenticate, do we just list files or are directories considered valid resources too? • For slow clients (or connections with high latency or low bandwidth), wouldn’t the nonce always be stale? • What do we do with the cnonce? • What do we do for content negotiation, 300, 301, 302 (i.e. items that have no effective ETag for use in a nonce)?

More Related