Subject: OpenPGP Signing of HTTP POST

From: "Arturo 'Buanzo' Busleiman" <[email-masked]>
Date: Tue, 06 Mar 2007 09:54:45 -0300

Dear OpenPGP WG team,

	One day at 3am in the morning I woke up with a mix of two strings in my head: "POST / HTTP/1.1" and
"-----BEGIN PGP SIGNED MESSAGE-----". I woke up my wife, told her about the whole idea, and as I
couldn't go back to sleep, I got up and wrote it down. A couple of months later, and some BIG
thinking, I decided to create a Firefox Extension to implement what I am now going to describe, and
what I want to rewrite into a proper Draft:

For years different methods for User Authentication and Session Management have been implemented:

    * HTTP Authentication
    * Cookies
    * GET/POST values
    * SSL with client certificates
    * A combination of all the above.

Regarding SMTP, e-mail has been digitally signed for a long time now, and it is a standard.
Extending its usage to the HTTP protocol sounded like a natural idea, specially at 3am when I woke
up with a OpenPGP-signed HTTP POST request in my head.

By having the POST payload ("variable=test") signed using an ASCII armored, Clearsign, OpenPGP based
procedure, the browsing user can provide Identity Authentication to that payload, thus adding all
OpenPGP benefits to the HTTP POST request.

This allows web developers to add a new layer of security to their applications, and if correctly
implemented will render man in the middle attacks useless. The direct benefit of implementing this
extension is that web developers will be able to verify the POST payload signature, potentially
avoiding obscure session management, and/or complicated login procedures.

For example, Highly Secure Home Banking sites could be created by using Enigform + some simple
server side code.

For a demo of an Enigform-based login procedure, with using AJAX and FORM SUBMIT, configure your
GnuPG, Install Enigform, then go to: http://enigformdemo.buanzo.com.ar.

Enigform: http://enigform.mozdev.org
Latest Version: 0.6.5

Work-in-progress draft: http://www.buanzo.com.ar/sec/enigform.en.html

Hope you like it!

- --
Arturo "Buanzo" Busleiman - Consultor Independiente en Seguridad Informatica
Mail Hosting Seguro y Consultoria - http://www.buanzo.com.ar/pro/

---

From: [email-masked] (Daniel A. Nagy)
Date: Tue, 6 Mar 2007 14:19:01 +0100

I think that this is extremely useful; I was enterntaining the same idea
myself, albeit in a slightly different way.

I think, that the standardized protocol needs to have facilities for both
client-, server- and content-authentication.

May I ask what the status of the draft is and how do you enter changes into
it?

---

From: "Arturo 'Buanzo' Busleiman" <[email-masked]>
Date: Tue, 06 Mar 2007 10:49:57 -0300

> myself, albeit in a slightly different way.

I had this idea in March/April 2006. Just had time to implement it last month :)

> client-, server- and content-authentication.

Yes, of course.

> May I ask what the status of the draft is and how do you enter changes into

The draft is behind the development status of the Enigform Firefox Extension. Currently, HTTP POST
requests generated via AJAX calls, or FORM submissions will be picked up for signing by Enigform by
checking if the ACTION URL (or Ajax request url) ends with "##ENIGFORM_Sign##". I had tested this
with a hidden input field of a special name/value combination, I've also tested using an extra
parameter for the <FORM> tag (SECURITY='ToBeSigned'), but all of this made the extension's code
overly complicated, and incompatible with certain sites. Checking the URL was quite a simpler approach.

Of course, the correct (i think) way for a FORM submission to be signed would be with a special
enctype (like urlencoded-openpgp-signed), but that would render ajax support useless, too.
Additionally, AJAX requests can't be diferentiated from form posts from within a Firefox extension.

Adoption of this technology is easier via a Firefox extension, and a simple set of server-side code
(that's why I talked with Rod, author of Smutty, to extend it with Enigform support).

Regarding changes to the draft, no specific procedures have been established, yet. This is my first
attempt. I'm open to suggestions.

- --

---

From: "Nickolay L." <[email-masked]>
Date: Tue, 6 Mar 2007 15:59:14 +0200

Hello Daniel,

Btw, in my plans also is writing and implementing something like 'PGP
security over HTTP' specification, and already having some ideas 'bout
it (it's something other than proposed by Arturo). Maybe, consider writing it in a group?

DAN> I think that this is extremely useful; I was enterntaining the same idea
DAN> myself, albeit in a slightly different way.

DAN> I think, that the standardized protocol needs to have facilities for both
DAN> client-, server- and content-authentication.

DAN> May I ask what the status of the draft is and how do you enter changes into
DAN> it?

--
  Best regards,Nickolay mailto:<[email-masked]>
      , .
     /_`,
    `' | &*._.,.
      .#      ) $,
     //./--//\\. &
     \/     \. \. -- - - ...   - - --.
    `'`'     `  `' -- - -  [> http://ansiart.org.ua <]
 [The Bat!3.80.03/Windows 5.1/Far 1.70(build 2087)]
 [Now playing : Пикник - Шарманка]

---

From: "Arturo 'Buanzo' Busleiman" <[email-masked]>
Date: Tue, 06 Mar 2007 11:47:58 -0300

> it (it's something other than proposed by Arturo). Maybe, consider writing it in a group?

Please, expand that! What are your ideas for OpenPGP security over http?

- --

---

From: "Arturo 'Buanzo' Busleiman" <[email-masked]>
Date: Tue, 06 Mar 2007 14:15:39 -0300

Nickolay L. wrote:
> Hello Arturo,

Hello, Nickolay. You forgot to reply to the list.

> ABB> Please, expand that! What are your ideas for OpenPGP security over http?
> Something like cleartext signing for HTTP - PGP-Signature headers and
> so on, and also encryption/binary signing of http document body.

Enigform currently adds an X-Enigform header with "Signed" value. I will be adding extra OpenPGP
parameters (fingerprint? keyid?), and the ability to also encrypt. Currently, only http POSTS are
supported. A signed request looks like this:

 POST /pba/postverify.php##ENIGFORM_Sign## HTTP/1.1
   Host: localhost
   User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) \
   Gecko/20070130 Firefox/2.0.0.1
   Accept: text/xml,application/xml,application/xhtml+xml,text/html\
   ;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
   Accept-Language: en-us,en;q=0.5
   Accept-Encoding: gzip,deflate
   Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
   Keep-Alive: 300
   X-Enigform: Signed
   Connection: keep-alive
   Referer: http://localhost/pba/
   Content-Length: 323
   Content-Type: application/x-www-form-urlencoded-openpgp
   Cache-Control: max-age=0

   -----BEGIN PGP SIGNED MESSAGE-----
   Hash: SHA1

   variable=test
   -----BEGIN PGP SIGNATURE-----
   Version: GnuPG v1.4.6 (GNU/Linux)
   Comment: POST signed using Enigform

   iD4DBQFFyMVnAlpOsGhXcE0RAmpcAJ9Lkqd/PZqVV/hoPFSoFZxizECKHwCY/rWd
   Z5AuIplmYgUFhTU3x3Sq9g==
   =wVHP
   -----END PGP SIGNATURE-----

What are the extra ideas you have?

- --

---

From: "Nickolay L." <[email-masked]>
Date: Tue, 6 Mar 2007 20:02:22 +0200

Hello Arturo,

>> so on, and also encryption/binary signing of http document body.

ABB> Enigform currently adds an X-Enigform header with "Signed"
ABB> value. I will be adding extra OpenPGP
ABB> parameters (fingerprint? keyid?), and the ability to also
ABB> encrypt. Currently, only http POSTS are
ABB> supported. A signed request looks like this:
ABB> What are the extra ideas you have?
Your format changes the HTTP protocol, which disables backward
compatibility, and could add other problems.
For example, we can do as following :

   POST /pba/postverify.php HTTP/1.1
   X-PGP-Message: Cleartext-Signed
   X-PGP-Signature-Hash: SHA1
   X-PGP-Signature-Version: GnuPG v1.4.6 (GNU/Linux)
   X-PGP-Signature-Comment: POST signed using Enigform
   X-PGP-Signature: iD4DBQFFyMVnAlpOsGhXcE0RAmpcAJ9Lkqd/PZqVV/hoPFSoFZxizECKHwCY/rWd
   Z5AuIplmYgUFhTU3x3Sq9g==
   Host: localhost
   User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) \
   Gecko/20070130 Firefox/2.0.0.1
   Accept: text/xml,application/xml,application/xhtml+xml,text/html\
   ;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
   Accept-Language: en-us,en;q=0.5
   Accept-Encoding: gzip,deflate
   Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
   Keep-Alive: 300
   Connection: keep-alive
   Referer: http://localhost/pba/
   Content-Length: 323
   Content-Type: application/x-www-form-urlencoded-openpgp
   Cache-Control: max-age=0

   variable=test

Where signature is to be calculated over all message (including header
fields) after X-PGP-Signature.

So, it will correspond to such OpenPGP message, which could be sent
to GnuPG for verification and so on :

   -----BEGIN PGP SIGNED MESSAGE-----
   Hash: SHA1

   Host: localhost

   variable=test

   -----END PGP SIGNATURE-----

Such simple translation on server and client side allows you to use
HTTP protocol as it is, and allows backwatds compatibility for
applications, which aren't compatible with such extensions.

I'm going to write complete draft of my ideas and publish it after
week or so.

---

From: "Arturo 'Buanzo' Busleiman" <[email-masked]>
Date: Tue, 06 Mar 2007 15:19:21 -0300

> Hello Arturo,

Hi Nickolay,

> compatibility, and could add other problems.

Remote sites have to tell the browser that the request should be signed, thus, only compatible sites
will receive such requests. In any case, I'm only modifying the body, and adding a header. No
request-specific structure is modified at all. Only proxies and/or content scanners and/or
webservers that make any kind of verification over the BODY might be problematic. In any case, as
Apache+PHP provide the RAW POST body, I don't think an openpgp signed body would make any problems.

Of course, I agree that the "##ENIGFORM_Sign##" tag is a quick hack, and that's why I'm here. An
official extension to the HTTP protocol, or better yet, a new content-encoding, should be analyzed.

> For example, we can do as following :
[...]
> fields) after X-PGP-Signature.

I thought about this, too.

What if other fields are added, after the X-PGP-Signature is calculated? What about [non]transparent
proxies? OpenPGP tags the beginning and end of the data that corresponds to the signature because of
that same reason.

- --

---

From: "Nickolay L." <[email-masked]>
Date: Tue, 6 Mar 2007 21:06:09 +0200

Hello Arturo,

ABB> Remote sites have to tell the browser that the request should be
ABB> signed, thus, only compatible sites
ABB> will receive such requests.
Sites can tell the browser, that request should be signed by using
simple header field, like 'X-OpenPGP-Signature-Needed: true'. And if
reply will be sent without signature, then server will throw to client
403 or any other error.

ABB> In any case, I'm only modifying the body, and adding a header. No
ABB> request-specific structure is modified at all. Only proxies and/or content scanners and/or
ABB> webservers that make any kind of verification over the BODY
ABB> might be problematic. In any case, as
ABB> Apache+PHP provide the RAW POST body, I don't think an openpgp
ABB> signed body would make any problems.

ABB> Of course, I agree that the "##ENIGFORM_Sign##" tag is a quick
ABB> hack, and that's why I'm here. An
ABB> official extension to the HTTP protocol, or better yet, a new
ABB> content-encoding, should be analyzed.
New content

>> For example, we can do as following :
ABB> [...]
>> fields) after X-PGP-Signature.

ABB> I thought about this, too.

ABB> What if other fields are added, after the X-PGP-Signature is
ABB> calculated? What about [non]transparent
ABB> proxies? OpenPGP tags the beginning and end of the data that
ABB> corresponds to the signature because of
ABB> that same reason.
If you are using non-transparent proxy, it means
1) you doesn't care about headers, they must not be signed - thus, you
can add parameter, something like 'X-OpenPGP-Signature-Param:
no-headers', which causes to sign/verify only the message body
(non-transparent proxies doesn't change message body, yep?)
2) if some headers are significant, there can be parameter, something
like 'X-OpenPGP-Validate-Headers: User-Agent, Accept-Charset, Referer'

---

From: Francisco Jesus Monserrat Coll <[email-masked]>
Date: Tue, 06 Mar 2007 20:44:31 +0100

El día Tue, 06 Mar 2007 09:54:45 -0300  "Arturo 'Buanzo' Busleiman" escribió:

Hello,

 Not regarding the "POST" method but to sign HTML pages there were 
some web pages, after reading 
http://members.aol.com/EJNBell/pgp-www.html 

we developed a similar method, hiding the PGP header,
http://www.rediris.es/pgp/firmaweb/index.en.html

 The idea was to not "overload" the web server with HTTPS security 
only to provide signed  web pages, but sign the web pages with PGP 
and place in a normal HTTP server, and later use PGP to check the web
page signature.
 
 With this option the web pages can be cached and verified , without 
using HTTP to protect the integrity of the web pages.

-- =
Francisco Jesus Monserrat Coll PGP key: http://www.rediris.es/keyserver
Rediris. Entidad Pública Empresarial Red.es 
Pza. Manuel Gómez Moreno, s/n Madrid 28014 SPAIN. tel +034 912127625

---

From: Ian G <[email-masked]>
Date: Tue, 06 Mar 2007 20:50:32 +0100

> proxies? OpenPGP tags the beginning and end of the data that corresponds to the signature because of

I suspect the question revolves around what you want to use 
the OpenPGP signature for.  Is it integrity, authentication, 
or authorisation?

Integrity would indicate a header-based binary signature and 
authorisation would prefer a cleartext signature over the 
body only.

For example, if you were authorising a financial 
transaction, you would want to get as close to the user as 
possible ... which admittedly is a hard or impossible task 
if the starting point is a POST.  If you seriously wanted 
reliable authorisation, in the sense of "sign here to 
authorise this money transfer" I'd look for something that 
sent a cleartext signed statement that was human 
interpretable, so that the human could review and confirm 
it.  That is, not a POST of variables at all, but a POST of 
a custom text based packet:

-----BEGIN PGP SIGNED MESSAGE-----

Action: TRANSFER
Source: 1233455
Target: 5433211
Value:  1000.00
Unit:   USD
Terms:  Appendix A.

-----BEGIN PGP SIGNATURE-----

yeahthisisajunksigyourclientshouldbarf
-----END PGP SIGNATURE------

With that form you can code up some form of proxy-based user 
client that independently of the Browser creates the signed 
authorisation ... which then means there is potential of a 
firewall between the Authorising soft/hardware and the 
Application software.

As soon as you hide that info from the user in for example a 
POST form, you will be at the mercy of technical attacks. 
How do you know that the veriables signed were in some way 
presented to the user?  In some courts, just the existence 
of these attacks will be enough to get it thrown out (e.g., 
Germany I am told tends to be very aggressive this way).

iang

---

From: "Arturo 'Buanzo' Busleiman" <[email-masked]>
Date: Tue, 06 Mar 2007 16:57:45 -0300

> using HTTP to protect the integrity of the web pages.

Yes, I read about it when I first researched the pgp and http terms in google. The only difference
in my case, is that I'm signing the requests the user/browser is sending to the web server, and not
the pages that are sent to the browser/user.

- --

---

From: "Arturo 'Buanzo' Busleiman" <[email-masked]>
Date: Tue, 06 Mar 2007 16:56:39 -0300

Ian G wrote:
> I suspect the question revolves around what you want to use the OpenPGP
> signature for.  Is it integrity, authentication, or authorisation?

All that is described in the URLs I sent in my original post.

- --