Subject: [webfinger] The HTTP/HTTPS Issue

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 Dec 2012 21:54:41 -0500

Folks,

I'm not sure we're any closer to agreement, but I don't think so.

What if we require servers to support both HTTP (directly or redirected to
HTTPS) and HTTPS, then letting the client select the transport it wants to
use given its own security requirements?

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 Dec 2012 21:58:32 -0500

Never mind that question.  If we go that path, we might as well just mandate
HTTPS.

So, who still is NOT in favor of just mandating use of HTTPS?

Paul

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul E. Jones
Sent: Thursday, December 13, 2012 9:55 PM
To: [email-masked]
Subject: [webfinger] The HTTP/HTTPS Issue

Folks,

Paul

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 19:00:06 -0800

On Thu, Dec 13, 2012 at 6:58 PM, Paul E. Jones <[email-masked]>wrote:

> Never mind that question.  If we go that path, we might as well just
> mandate HTTPS.
>

Phew, that saved me a very confused email.  Yes.

> ****
>
> ** So, who still is NOT in favor of just mandating use of HTTPS?
>

Also curious on this.

---

From: James M Snell <[email-masked]>
Date: Thu, 13 Dec 2012 19:15:53 -0800

On Dec 13, 2012 6:54 PM, "Paul E. Jones" <[email-masked]> wrote:
>
> Folks,
>
>
>
> I’m not sure we’re any closer to agreement, but I don’t think so.
>
>
>
> What if we require servers to support both HTTP (directly or redirected
to HTTPS) and HTTPS, then letting the client select the transport it wants
to use given its own security requirements?

The spec language you posted earlier, with the changes you and I discussed,
is spot on.

-1 to mandating HTTPS.

- James

>
>
> Paul
>
>
>
>
> _______________________________________________
> webfinger mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webfinger
>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 13 Dec 2012 19:20:45 -0800

+1 on mandating HTTPS

The internet is not static. I can imagine providers innovating on providing HTTPS if WF becomes popular.

On Dec 13, 2012, at 7:00 PM, Brad Fitzpatrick <[email-masked]> wrote:

> On Thu, Dec 13, 2012 at 6:58 PM, Paul E. Jones <[email-masked]> wrote:
> Never mind that question.  If we go that path, we might as well just mandate HTTPS.
> 
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 Dec 2012 22:36:19 -0500

James, et  al,

I that text still seemed to be controversial, since it would mean there is a possibility that clients requiring secure connections would fail when a domain did not implement WF on HTTPS.

Let me present it again:

    Clients MAY issue a query to the WebFinger server using either

    HTTPS or HTTP, but MUST NOT attempt to use both, either serially

    or in parallel.  The choice of transport protocols depends on the

    client’s security requirements, though use of HTTPS is

    RECOMMENDED in most situations.

    If a query is issued using HTTPS and the server has an invalid

    certificate, the server returns a 4xx or 5xx status code, or the

    HTTPS connection cannot be established for any reason, the client

    MUST accept that the WebFinger query has failed and MUST NOT

    attempt to reissue the WebFinger request using HTTP.

    WebFinger servers operating on HTTP MAY redirect a client using

    an appropriate HTTP status code to another HTTP or an HTTPS URI.

    Likewise, WebFinger servers operating on HTTPS MAY redirect a

    client to another HTTPS URI, but MUST NOT redirect a client to an

    HTTP URI.  Further, clients MUST NOT follow a redirection from an

    HTTPS URI to an HTTP URI, but SHOULD automatically follow all

    other server redirects.

Do we go with this or do we mandate HTTPS only?  (I’ve tried to not take a position on this, but it does seem like the more we go back and forth and discuss pros and cons, HTTPS is looking much simpler. It does mean domain owners will have to get a certificate and it will not work on hosting providers that do not support SNI.  However, I would assume that the number of such providers is dwindling now that SNI has been in OpenSSL for a few years.)

Paul

From: James M Snell [mailto:[email-masked]] 
Sent: Thursday, December 13, 2012 10:16 PM
To: Paul E. Jones
Cc: [email-masked]
Subject: Re: [webfinger] The HTTP/HTTPS Issue

On Dec 13, 2012 6:54 PM, "Paul E. Jones" <[email-masked]> wrote:
> What if we require servers to support both HTTP (directly or redirected to HTTPS) and HTTPS, then letting the client select the transport it wants to use given its own security requirements?
>

The spec language you posted earlier, with the changes you and I discussed, is spot on.

-1 to mandating HTTPS.

- James

---

From: James M Snell <[email-masked]>
Date: Thu, 13 Dec 2012 19:38:39 -0800

Failure of a request is perfectly acceptable. If the client needs a secured
connection and the server simply does not provide for it, the client simply
won't use that server. Simple as that.
On Dec 13, 2012 7:36 PM, "Paul E. Jones" <[email-masked]> wrote:

> James, et  al,****
>
> ** **
>
> I that text still seemed to be controversial, since it would mean there is
> a possibility that clients requiring secure connections would fail when a
> domain did not implement WF on HTTPS.****
>
> ** **
>
> Let me present it again:****
>
> ** **
>
>     Clients MAY issue a query to the WebFinger server using either****
>
>     HTTPS or HTTP, but MUST NOT attempt to use both, either serially****
>
>     or in parallel.  The choice of transport protocols depends on the****
>
>     client’s security requirements, though use of HTTPS is****
>
>     RECOMMENDED in most situations.****
>
> ** **
>
>     If a query is issued using HTTPS and the server has an invalid****
>
>     certificate, the server returns a 4xx or 5xx status code, or the****
>
>     HTTPS connection cannot be established for any reason, the client****
>
>     MUST accept that the WebFinger query has failed and MUST NOT****
>
>     attempt to reissue the WebFinger request using HTTP.****
>
> ** **
>
>     WebFinger servers operating on HTTP MAY redirect a client using****
>
>     an appropriate HTTP status code to another HTTP or an HTTPS URI.****
>
>     Likewise, WebFinger servers operating on HTTPS MAY redirect a****
>
>     client to another HTTPS URI, but MUST NOT redirect a client to an****
>
>     HTTP URI.  Further, clients MUST NOT follow a redirection from an****
>
>     HTTPS URI to an HTTP URI, but SHOULD automatically follow all****
>
>     other server redirects.****
>
> ** **
>
> Do we go with this or do we mandate HTTPS only?  (I’ve tried to not take a
> position on this, but it does seem like the more we go back and forth and
> discuss pros and cons, HTTPS is looking much simpler. It does mean domain
> owners will have to get a certificate and it will not work on hosting
> providers that do not support SNI.  However, I would assume that the number
> of such providers is dwindling now that SNI has been in OpenSSL for a few
> years.)****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* James M Snell [mailto:[email-masked]]
> *Sent:* Thursday, December 13, 2012 10:16 PM
> *To:* Paul E. Jones
> *Cc:* [email-masked]
> *Subject:* Re: [webfinger] The HTTP/HTTPS Issue****
>
> ** **
>
>
> The spec language you posted earlier, with the changes you and I
> discussed, is spot on.****
>
> -1 to mandating HTTPS.****
>
> - James****
>
> >
> >
> > Paul
> >
> >
> >
> >

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 20:40:43 -0800

On Thu, Dec 13, 2012 at 7:38 PM, James M Snell <[email-masked]> wrote:

> Failure of a request is perfectly acceptable. If the client needs a
> secured connection and the server simply does not provide for it, the
> client simply won't use that server. Simple as that.
>
I don't want users or clients to need to opt-in to security.

---

From: John Bradley <[email-masked]>
Date: Fri, 14 Dec 2012 07:17:48 -0200

I am on record supporting  https: only as the only sane way to have a simple client with security. 

John B. 

Sent from my iPad

---

From: Goix Laurent Walter <[email-masked]>
Date: Fri, 14 Dec 2012 10:42:58 +0100

We’re talking about clients but not applications. If clients are the implementation stacks of the spec, then they should give the whole flexibility of it. It is up to the app (representing the specific use-case) to decide whether it needs security or not, and whether fallback may be acceptable or not. If https-to-http fallback is performed at application level and not automatically by the client then we may all converge.

Let me give an example:

-          Use case type 1 (“autoconfiguration/login”): My website is providing registration through openidconnect where the user can input his identity. Since this is what I can call autoconfiguration use case (in that sense similar to discovering my oauth* endpoints) the app (my website) 1) needs security and 2) knows pretty much the link rels it’s interested in. it then issues the wf request over https only (optionally adding the explicit list of links). If that request fails because the idp is not running over https, then my website (nor the underlying wf client) does not fallback over http and tells the user that he cannot use that identity. Similarly if I want to autoconfigure my favorite app based on my identity and discover a bunch of endpoints my client should not fallback to http.

-          Use case type 2 (“public info discovery”): My favorite email app has a plugin that resolves email addresses to show the user’s avatar. For each email address it issues a wf request and can decide whether to try https first or directly http. Suppose it *asks the client to try https first (may be the default)*. If the client fails for the same reason, then *the app* can decide to try again over plain http and decide what to do with the provided information (eg accept it as avatar may be considered less sensitive).

If we move the security concern at app level then we need a mechanism to tell so, which is independent from the specific codebase and/or api signature. One possibility could be in the resource URI itself that we are querying. We already said that any type of uri is supported with a specific mention of acct:. What about introducing accts: for this purpose? Sips:, wss:, https: are all examples of uris that explicitly call for tls. In that case if the app requests wf.discover(“accts:[email-masked]”) the client would know that it has to run over https. And it works for https: URIs as well and others.

With this artifact we can get rid of the fallback problem on the client side and stay with the current text in saying that it must not try in parallel or in sequence (meant as “automatically”). But it may be requested to do so by the app if after a failure over https (eg for use case type 2) the app decides to go over plain http (using acct: URI).

What I would update is simply that server MUST expose over http and SHOULD over HTTPS so that every case works with the above scenario, further clarifying (as shared with nick) that servers MUST NOT include 'secure' *href* (the ones whose scheme is ending with an ‘s’) when answering over plain http AND clients MUST ignore those hrefs should they be anyway included in the jrd retrieved over http (as an attack).
As paul pointed out the only limitation is if my avatar is only exposed over an https endpoint but not my wf endpoint but I don’t think this is a real issue…

walter

Da: [email-masked] [mailto:[email-masked]] Per conto di Brad Fitzpatrick
Inviato: venerdì 14 dicembre 2012 5.41
A: James M Snell
Cc: Paul E. Jones; [email-masked]
Oggetto: Re: [webfinger] The HTTP/HTTPS Issue

On Thu, Dec 13, 2012 at 7:38 PM, James M Snell <[email-masked]<mailto:[email-masked]>> wrote:

Failure of a request is perfectly acceptable. If the client needs a secured connection and the server simply does not provide for it, the client simply won't use that server. Simple as that.
I don't want users or clients to need to opt-in to security.

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: Mikael Nordfeldth <[email-masked]>
Date: Fri, 14 Dec 2012 12:07:33 +0100

PLEASE remember that mandating HTTPS implies that EVERY single 
Wordpress (or other mass-hosted FOSS) blog out there will REQUIRE https 
for it to serve webfinger data.

What a marvellous thing it would be if every Wordpress installation in 
the world could overnight get Webfinger support. Just like that! A 
software update and suddenly there are TENS OF MILLIONS of Webfinger 
implementations!

A blog like your average Wordpress won't have any real authenticity in 
itself. Anyone can open up a blog with any pseudonym and publish data 
pretending to be someone. But their METADATA is still usable for OTHER 
bloggers/etc! Also, the blog's webfinger could link to the same 
pseudonym's social web accounts and such.
(where in the end a human is more likely to use the data and verify it 
than any automated mechanism)

And there's no reason for HTTPS-only clients to connect at all to a 
non-HTTPS resource. So they won't be buggered by all these critters with 
blogs!

But this vast implementation outside of corporate use will only be 
reality if we allow Webfinger use for your average blogger-type-of-user.

...and some more elaboration for the ones who have time to read it all:

14.12.2012 04:36 skrev Paul E. Jones:
> I that text still seemed to be controversial, since it would mean
> there is a possibility that clients requiring secure connections 
> would
> fail when a domain did not implement WF on HTTPS.

Yes, just as my web browser "fails" when I try to access 
futurelotteryticketnumbers.com to retrieve authentic lottery ticket 
numbers that will give me millions of dollars.

If HTTPS doesn't exist, and you require it, you can't connect to it. 
Tough luck, not every domain in the world will implement Webfinger 
anyway.
If your client requires HTTPS due to the contents of the request/reply, 
and HTTPS isn't available, then it will fail. No surprise.

The amount of "failures" in this sense will be _much_ larger if 
verified-https-only is mandated. For no apparent reason, as there is no 
guarantee the actual DATA over HTTPS is true anyway. There are tons of 
cases where you just want data - any data - which can later be verified 
by a third party.

Example of non-trustworthy data (out of band for HTTPS certificate 
verification):
* I can do a rel-me with mailto:[email-masked]
* This can only be falsified by a human unless we're increasing the 
complexity of data verification, second-server lookups and requiring 
Webfinger use on every domain out there)

-- 
Mikael Nordfeldth
http://blog.mmn-o.se/
[email-masked]
+46705657637

---

From: Goix Laurent Walter <[email-masked]>
Date: Fri, 14 Dec 2012 13:26:12 +0100

(Re sending including the google group)

Da: Goix Laurent Walter
Inviato: venerdì 14 dicembre 2012 10.43
A: 'Brad Fitzpatrick'; James M Snell
Cc: Paul E. Jones; [email-masked]
Oggetto: R: [webfinger] The HTTP/HTTPS Issue

Let me give an example:

walter

---

From: Nick Jennings <[email-masked]>
Date: Fri, 14 Dec 2012 16:19:31 +0100

I pretty much agree with what Goix is explaining here. The more I think
about it, though, the more I think we're worrying way too much about
'client complexity'. The client will be complex, we're programmers, we can
handle that. It's not a big deal. What's important is that we a) make clear
the security implications, and precautions to consider for potential client
developers b) make sure the servers will take sufficient responsibility for
the data they provide to not become compromised due to a bug in a client
library. Other than those two points, i think we need to make WF as
flexible and applicable to the different use-cases as possible (for
wide-spread server adoption). That means:

(A)   Servers MUST answer on HTTP and SHOULD answer on HTTPS. A server MAY
upgrade an HTTP request to HTTPS if they want all of their data to be
retrieved via HTTPS.

 -- This accounts for those that do not want to have to purchase a cert
just to participate in providing lookup ability for simple user data.
Wordpress blogs, simple one-man domains, etc.

(B)   Servers MUST filter 'secure' data from HTTP replies

 -- How 'secure' data is defined is still up in the air, but I think it's
sufficiently clear that this needs to happen to some degree to protect
against possible MITM attacks or poorly implemented client libraries.

(C)   Client libraries SHOULD NOT use HTTP for any secure data retrieval
AND MUST filter any 'secure' links from an HTTP response.

(D)   Client libraries MAY provide fallback (HTTP->HTTPS or vice versa) as
a configuration option, BUT IF SO:

   1. They MUST NOT fallback to HTTP when accessing secure information.
   2. They MUST provide a method of disabling fallback and specifying one
protocol for the attempt(s).

I think that covers all our use cases, and takes care of (1: security) and
(2: HTTP)... I think client complexity is a much better sacrifice to make
here for several reasons:

1. This only works if there are a lot of servers adopting WF

2. There will (hopefully) be MANY more servers than client libraries

3. You don't have to be a WF nerd to get a server going ... and (below)...

4. If you want to WRITE a client library, you're going to be more technical
and are more than likely going to read the spec. / know a thing or two. And
if you don't so what? (the servers can handle it if they follow the spec)

I think those points make client complexity the clear compromise.
What do you guys think?
-Nick

On Fri, Dec 14, 2012 at 1:26 PM, Goix Laurent Walter <
[email-masked]> wrote:

>  (Re sending including the google group)****
>
> ** **
>
> *Da:* Goix Laurent Walter
> *Inviato:* venerdì 14 dicembre 2012 10.43
> *A:* 'Brad Fitzpatrick'; James M Snell
>
> *Cc:* Paul E. Jones; [email-masked]
> *Oggetto:* R: [webfinger] The HTTP/HTTPS Issue****
>
>  ** **
>
> We’re talking about clients but not applications. If clients are the
> implementation stacks of the spec, then they should give the whole
> flexibility of it. It is up to the app (representing the specific use-case)
> to decide whether it needs security or not, and whether fallback may be
> acceptable or not. If https-to-http fallback is performed at application
> level and not automatically by the client then we may all converge. ****
>
> ** **
>
> Let me give an example:****
>
> **-          **Use case type 1 (“autoconfiguration/login”): My website is
> providing registration through openidconnect where the user can input his
> identity. Since this is what I can call autoconfiguration use case (in that
> sense similar to discovering my oauth* endpoints) the app (my website) 1)
> needs security and 2) knows pretty much the link rels it’s interested in.
> it then issues the wf request over https only (optionally adding the
> explicit list of links). If that request fails because the idp is not
> running over https, then my website (nor the underlying wf client) does not
> fallback over http and tells the user that he cannot use that identity.
> Similarly if I want to autoconfigure my favorite app based on my identity
> and discover a bunch of endpoints my client should not fallback to http.**
> **
>
> **-          **Use case type 2 (“public info discovery”): My favorite
> email app has a plugin that resolves email addresses to show the user’s
> avatar. For each email address it issues a wf request and can decide
> whether to try https first or directly http. Suppose it **asks the client
> to try https first (may be the default)**. If the client fails for the
> same reason, then **the app** can decide to try again over plain http and
> decide what to do with the provided information (eg accept it as avatar may
> be considered less sensitive).****
>
> ** **
>
> If we move the security concern at app level then we need a mechanism to
> tell so, which is independent from the specific codebase and/or api
> signature. One possibility could be in the resource URI itself that we are
> querying. We already said that any type of uri is supported with a specific
> mention of acct:. What about introducing accts: for this purpose? Sips:,
> wss:, https: are all examples of uris that explicitly call for tls. In that
> case if the app requests wf.discover(“accts:[email-masked]”) the client
> would know that it has to run over https. And it works for https: URIs as
> well and others.****
>
> ** **
>
> With this artifact we can get rid of the fallback problem on the client
> side and stay with the current text in saying that it must not try in
> parallel or in sequence (meant as “automatically”). But it may be requested
> to do so by the app if after a failure over https (eg for use case type 2)
> the app decides to go over plain http (using acct: URI).****
>
> ** **
>
> What I would update is simply that server MUST expose over http and SHOULD
> over HTTPS so that every case works with the above scenario, further
> clarifying (as shared with nick) that servers MUST NOT include 'secure'
> *href* (the ones whose scheme is ending with an ‘s’) when answering over
> plain http AND clients MUST ignore those hrefs should they be anyway
> included in the jrd retrieved over http (as an attack). ****
>
> As paul pointed out the only limitation is if my avatar is only exposed
> over an https endpoint but not my wf endpoint but I don’t think this is a
> real issue…****
>
> ** **
>
> walter****
>
> ** **
>
> *Da:* [email-masked] [mailto:[email-masked]] *Per
> conto di *Brad Fitzpatrick
>
> *Inviato:* venerdì 14 dicembre 2012 5.41
> *A:* James M Snell
> *Cc:* Paul E. Jones; [email-masked]
> *Oggetto:* Re: [webfinger] The HTTP/HTTPS Issue****
>
>  ** **
>
> On Thu, Dec 13, 2012 at 7:38 PM, James M Snell <[email-masked]> wrote:*
> ***
>
> client simply won't use that server. Simple as that.****
>
>  I don't want users or clients to need to opt-in to security.****
>
> ** **
>      Questo messaggio e i suoi allegati sono indirizzati esclusivamente
> alle persone indicate. La diffusione, copia o qualsiasi altra azione
> derivante dalla conoscenza di queste informazioni sono rigorosamente
> vietate. Qualora abbiate ricevuto questo documento per errore siete
> cortesemente pregati di darne immediata comunicazione al mittente e di
> provvedere alla sua distruzione, Grazie.
>
> *This e-mail and any attachments** is **confidential and may contain
> privileged information intended for the addressee(s) only. Dissemination,
> copying, printing or use by anybody else is unauthorised. If you are not
> the intended recipient, please delete this message and any attachments and
> advise the sender by return e-mail, Thanks.*
> *Rispetta l'ambiente. Non stampare questa
> mail se non è necessario.*
>
>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 14 Dec 2012 09:36:38 -0800

I think that a good spec enables applications to implement the specs directly, so there is no difference between clients and apps. OAuth 2.0 does not need a library to implement the client.

-- Dick

On Dec 14, 2012, at 1:42 AM, Goix Laurent Walter <[email-masked]> wrote:

> <logo Ambiente_foglia2.jpg>Rispetta l'ambiente. Non stampare questa mail se non è necessario.
> 
> <logo Ambiente_foglia2.jpg>_______________________________________________
> webfinger mailing list
> [email-masked]

---

From: Nick Jennings <[email-masked]>
Date: Fri, 14 Dec 2012 18:48:26 +0100

On Fri, Dec 14, 2012 at 6:36 PM, Dick Hardt <[email-masked]> wrote:

> I think that a good spec enables applications to implement the specs
> directly, so there is no difference between clients and apps. OAuth 2.0
> does not need a library to implement the client.
>
>
You don't *need* a client here as well, it's just an HTTP/S request (one OR
two if you really want to cover your bases). That's all. In this case, the
client library is to make things as simple as possible, not to make things
possible at all.

> -- Dick
>
> On Dec 14, 2012, at 1:42 AM, Goix Laurent Walter <
> level and not automatically by the client then we may all converge.****
>
> -          Use case type 1 (“autoconfiguration/login”): My website is
> -          Use case type 2 (“public info discovery”): My favorite email
> app has a plugin that resolves email addresses to show the user’s avatar.
> For each email address it issues a wf request and can decide whether to try
> https first or directly http. Suppose it **asks the client to try https
> first (may be the default)**. If the client fails for the same reason,
> then **the app** can decide to try again over plain http and decide what
> to do with the provided information (eg accept it as avatar may be
> considered less sensitive).****
>
> included in the jrd retrieved over http (as an attack).****
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
>
> *<logo Ambiente_foglia2.jpg>Rispetta l'ambiente. Non stampare questa mail
> se non è necessario.*
>

---

From: Mikael Nordfeldth <[email-masked]>
Date: Fri, 14 Dec 2012 21:08:20 +0100

> upgrade an HTTP request to HTTPS if they want all of their data to be

I just wish to point out that it's entirely legitimate NOT to listen to 
HTTP at all. There's no reason an HTTPS server must also serve HTTP.

So there's no point in requiring the use of either protocol. The chosen 
protocol should be up to the client (purpose) and the situation 
(content). And the worst case scenario, which is far from applicable in 
every situation, is a two-round trip. But as a Webfinger client, I can 
have a personal policy of verified-HTTPS-only (which I believe many of 
the "+1 HTTPS-only" people will have) and not be bothered at all with 
the non-HTTPS implementations out there.

Not forcing any combination - and leaving the protocol to the client - 
is the best, most humble way of avoiding issues caused by unfortunate 
implicit encryption that HTTPS is. (and I think discussing a possible 
future of STARTTLS over HTTP is pretty much off-topic here).

-- 
Mikael Nordfeldth
http://blog.mmn-o.se/
[email-masked]
+46705657637