INTERNET-DRAFT Expiration: November 2002 Kai Kretschmann Michael Krech Document: draft-kretschmann-kai-sighttp-00.txt May 2002 Signed HTTP with static and dynamic content as a security enhance- ment against silent defacements. Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract In case a webserver gets defaced a black hat might change vital information with massive danger for the normal surfer. If for example a banking web portal site containing a link to the online banking login screen gets changed pointing to the black hats identical mirror of the login screen (as happend here some times already) he will get his hands on real banking accounts. The encryption via SSL of already defaced data will be no solution at all. SSL is only a counterpart in this Kretschmann/Krech draft-kretschmann-kai-sighttp-00.txt [Page 1] Internet Draft SigHTTP May 2002 scenario to ensure the connected web server is the right one and to dis- able data sniffing on the wire. The solution to this case might be signing all HTTP-accessable con- tent including static and dynamic HTML pages. This solution even keeps an eye on dynamic portal content, as most starting pages now have dynamic content on it, starting from the current time to brokerage news. Best solution would never the less be to have the critical data within static pages. We can sign any URL based content because the signature doesn't get into the content sent, but into the HTTP reply headers. So we don't modify any data. The HTTP reply doesn't need any change within the web- server source code but can most times be configured by standard configu- ration ways. Signing not only HTML but possibly any critical data is needed for example with a flash movie who display critical data like online broker- age data. This data might be forged by replacing a lying flash movie with possibly bad consequences to stock rates. One shouldn't underesti- mate the criminal energy in these cases. Certificate structure Depending of the way the public key reaches the web client we don't need a certificate structure at all. Given the case of an online banking portal the clients already receive some critical data like pin codes via postal mail. One could deliver the public key including any needed applications to check the content with postal mail, too. In case we deliver the public key online from the same webserver it would be better to sign/certify this public key with a third parties signature as already done with SSL certificates. The certificate structure is identical to the established one for SSL certificates for web channel encryption with the difference that the private key must not reside on the webservers devices. This example implementation uses the openssl package to create self signed certifi- cates for signing html pages. 1. We start with a copy of openssl.cnf in the current directory with preconfigured path and key data. 2. Then we create the root certificate key. This part will be done by a certification company. 3. We create a key and certificate request for the webserver itself. The current domainname should be used in the key similar to SSL Kretschmann/Krech draft-kretschmann-kai-sighttp-00.txt [Page 2] Internet Draft SigHTTP May 2002 requests. 4. The webservers certification requests gets signed with the private key of our root certificate. This part will be done by a certifi- cation company. 5. Now we can sign using the private key of the webserver. Not only html, but also java archives, flash movies or any other file based content might be signed. Example of creating a certificate structure by hand using openssl command line tools: openssl req -new -x509 -keyout private/root.key.pem -out private/root.cert.pem -config openssl.cnf openssl req -new -keyout client.key.pem -out client.req.pem -days 360 -config openssl.cnf cat client.key.pem client.req.pem >client.pem openssl ca -policy policy_anything -out client.cert.pem -config openssl.cnf -infiles client.pem Signing Sign the file xmpl1.html using the private key ssl/client.key.pem and create the detached signature into the temporary binary file xmpl1.html.sig: openssl dgst -sha1 -sign ssl/client.key.pem -out xml1.html.sig xmpl1.html This gives you the result displayed in hex: SHA1(xmpl1.html)= 2e28a196f32120f39c5109488701585d6dccf84bdc57b93e88531330a1c8dd321e5451157069d642486ce64995c64f5c6779e3337 1480c4e51a3c7b72873bdb56bd2f225b19c8cc64e4dc2f9032095a9b0f25f6f61d8f990f786a7db8204038a Transform the binary content to a transmittable hex encoding and prepend the line with the right http header, including a introducing line describing the algorithm. Write it into a file within the sub folder .meta: SigHTTP-algorithm: sha1 SigHTTP-signature: 2e28a196f3212...9b0f25f6f61d8f990f786a7db8204038a Webserver As an example we configure the most common web server apache using the standard module mod_cern_meta using these lines in a local .htaccess file: Kretschmann/Krech draft-kretschmann-kai-sighttp-00.txt [Page 3] Internet Draft SigHTTP May 2002 MetaFiles on MetaDir .meta MetaSuffix .sign Signatures will now be served from the sub folder /.meta/ with a filename like xmpl1.html.sign Web client The HTTP reply header lines can be watched using wget: kai@fix:/tmp/x > wget -S http://www.security-gui.de/d/xmpl1.html --15:29:12-- http://www.security-gui.de/d/xmpl1.html => `xmpl1.html' Verbindungsaufbau zu proxy.kaikretschmann.de:3128... verbunden! Proxy Anforderung gesendet, warte auf Antwort... 200 OK 2 Date: Thu, 09 May 2002 13:29:14 GMT 3 Server: Apache (SuSE/Linux) 4 SigHTTP-algorithm: sha1 5 SigHTTP-signature: 2e28a196f3212...9b0f25f6f61d8f990f786a7db8204038a 6 Last-Modified: Wed, 08 May 2002 17:03:10 GMT 7 ETag: "327cd-134-3cd95a4e" 8 Accept-Ranges: bytes 9 Content-Length: 308 10 Content-Type: text/html 11 X-Cache: MISS from fix.kaikretschmann.de 12 Proxy-Connection: close 13 Verification On the client side we need the public key of the webserver. We have to get the key from a trusted third party, otherwise the public key might have been defaced by any intruder with his own, making a new valid signature of his defaced html pages. The public key could be distributed by postal mail for selected customers in case of for example online banking clients. Testing for a valid signature by hand using the openssl tools would work the follwing way, we first extract the public key from the web- servers certification key. openssl x509 -inform PEM -outform PEM -in ssl/client.cert.pem -pubkey openssl dgst -sha1 -verify ssl/client.pubkey.pem -signature xmpl1.html.sign xmpl1.html Kretschmann/Krech draft-kretschmann-kai-sighttp-00.txt [Page 4] Internet Draft SigHTTP May 2002 Automation 1. Generating signatures would be done from a different computer than the webserver itself, because the private signing key must not reside on any webserver accessible device. There will be a simple frontend for doing this with integrated signature upload, either scp, webdav or ftp. 2. The client side verification will be integrated within the web browser itself by some sort of plugin. 3. If the client browser cannot use the plugin there will be a stan- dalone java application which checks the signature of a given URL. 4. If no local application is allowed one could use some web service of a trusted third party which checks the given URL via some web frontend. In case of defaced web content and resulting signature verification failure the client might ask for sending the webmaster mailalias of the webserver a indication of the case. Dynamic HTML For signing partly dynamic HTML content we have to introduce one new HTML-Tag . For example given a banking web portal most content will be static and able to be signed. Only some areas are client depended or in any other way dynamically filled with every request. Because the private key must not reside on the webserver for security reasons we cannot com- pute a new signature in realtime. So we exclude the areas within every html file which must not be included in either computation or verifica- tion of the signature. The newly introduced tag has to be included in the signature process. To go even further one should describe the allowed dynamic content using one defined optional parameter attribute of the tag, the attribute type. We will have the following defined types: type="text" Floating text without any html tags but with optional html entities for special characters. type="numeric" Any numeric display, including time or other numbers with seperat- ing characters like "," and ".". Kretschmann/Krech draft-kretschmann-kai-sighttp-00.txt [Page 5] Internet Draft SigHTTP May 2002 type="styletext" Like type text but with some formatting tags allowed, like , or . type="locallink" Like type styletext but with tags allowed, as far as they ref- erence only URIs local to the actual server. It is the duty of the verifying client program to mandatory test the fulfillment of the dynamic restrictions. In case of dynamic gener- ated session IDs it has to be implemented using cookies or dynamic sub- domain host parts. A miniature dynamic portal site would look like this example: Hello, today we have the time: . Author's Address: K. Kretschmann / M. Krech security-gui.de GbR Giessen, Germany http://www.security-gui.de/ K.Kretschmann@security-gui.de, M.Krech@security-gui.de This draft expires november 2002 Kretschmann/Krech draft-kretschmann-kai-sighttp-00.txt [Page 6]