"Comet" URLs make it difficult to properly set up SSL

[AlainKnaff]

On some browsers (such as Opera and Konqueror) but not on others (Firefox, Midori, Nokia N900), etherpad generates URLs such as

2143539285689.comet.hitchhiker.org.lu

This makes it difficult to properly set up SSL, as this would need a wildcard certificate (*.comet.hitchhiker.org.lu) which are prohibitively expensive on some CAs.

On other CAs (such as startssl.com class2) they are affordable, but even there these URLs would cause problems as soon as you throw "team sites" in the mix.

Indeed, visiting a pad in a team site ("sub") with one of the 2 affected browsers will query an URL such as the following:

2143539285689.comet.sub.hitchhiker.org.lu

In order to cover this, you'd need a wildcard certificate for .comet..hitchhiker.org.lu However, even startSSL refuses to issue such double wildcard certificates...

Wouldn't it be preferable to generate the "comet" URLs at local paths rather than sub domains? (hitchhiker.org.lu/comet/243y736) Or is this just a case of browsers "seeing things"...

[AlainKnaff]

Weird... Rejecting the certificate makes the warnings shut up with no obvious impediment to function...

[JohnMcLear]

FYI Etherpad Lite has an implementation where it uses a directory path instead of a subdomain.

Take a look at that and copy/paste how it's done.

-----Original Message----- From: AlainKnaff [mailto:reply@reply.github.com] Sent: 12 November 2011 19:43 To: John McLear Subject: [pad] "Comet" URLs make it difficult to properly set up SSL (#306)

On some browsers (such as Opera and Konqueror) but not on others (Firefox, Midori, Nokia N900), etherpad generates URLs such as

2143539285689.comet.hitchhiker.org.lu

This makes it difficult to properly set up SSL, as this would need a wildcard certificate (*.comet.hitchhiker.org.lu) which are prohibitively expensive on some CAs.

On other CAs (such as startssl.com class2) they are affordable, but even there these URLs would cause problems as soon as you throw "team sites" in the mix.

Indeed, visiting a pad in a team site ("sub") with one of the 2 affected browsers will query an URL such as the following:

2143539285689.comet.sub.hitchhiker.org.lu

In order to cover this, you'd need a wildcard certificate for .comet..hitchhiker.org.lu However, even startSSL refuses to issue such double wildcard certificates...

Wouldn't it be preferable to generate the "comet" URLs at local paths rather than sub domains? (hitchhiker.org.lu/comet/243y736) Or is this just a case of browsers "seeing things"...

---

Reply to this email directly or view it on GitHub: https://github.com/ether/pad/issues/306 This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of the organisation from which this email originated. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error. This email was sent by School Email - Safe Webmail and Hosted Email for Schools;/p>

[AlainKnaff]

Interesting... but in any case, I just noticed that in /usr/share/etherpad/infrastructure/net.appjet.ajstdlib/streaming-client.js, I can just set canUseSubdomains to 0, and then this no longer occurs... weird...

maybe canUseSubdomains should automatically default to 0 if https is used...

[sesam]

It is guaranteed to slow down the operation of pads. Does anyone know the purpose of canUseSubdomains? Maybe it's been mentioned on either of the maillists? Could it be needed for one browser to have multiple pads open perhaps? (Guessing more; to keep separate cookie state between different pad documents?)