Re: [jdev] virtual hosting and certificate checking
On Friday 03 March 2006 23:10, Richard Dobson wrote: > > Funnily enough, if we'd had naming in TLS from the start, there probably > > wouldn't even *be* STARTTLS since everyone would be using the better > > method. :-) > > I doubt that since the main reason STARTTLS is there is so that you can > reuse the same port for both encrypted and unencrypted versions of a > protocol not really so you can pass the desired hostname, thats just a > side benefit of being able to start out unencrypted. But wouldn't it then be easier to endorse using _only_ the encrypted version? TX -- Email: [EMAIL PROTECTED] Jabber ID: [EMAIL PROTECTED] Web site: http://trypticon.org/ GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F A62C B8C7 BC8B 037E EA73 pgpmCBwq4QGzY.pgp Description: PGP signature
Re: [jdev] Jabber-ID email header
Honestly, what convinced me was someone pointing out that it is called a "JID", short for "Jabber ID". For some reason I neglected to remember this. On Mar 1, 2006, at 12:25 PM, Peter Saint-Andre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hal Rottenberg wrote: On 3/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED]> wrote: Another +1 to XMPP-ID. 1. The protocol standard is XMPP (and not Jabber) - all our efforts should be behind the "XMPP" bandwagon. Yes, but even so the "from" header isn't called "SMTP-ID", it's called "from". +1 for the more human-friendly Jabber-ID Well, I already submitted the Internet-Draft on it anyway. ;-) P - -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEBgMzNF1RSzyt3NURAuLoAKCuegvBRh0PiU7ozAWLNVqXLjNEzQCdESSi qD33DzNFul/X9FWH5lNeMtU= =Bztm -END PGP SIGNATURE- __ Robert Quattlebaum Mobile: +1(650) 223-4974 eMail: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] MSN:[EMAIL PROTECTED] AIM/ICQ:rquat2 yahoo: robert_quattlebaum
[jdev] SamePlace 0.2.9+0.3.0prealpha
An alpha of SamePlace is online at http://www.sameplace.cc/alpha. SamePlace is a Jabber client for Firefox. Besides normal operation, it allows the user to "enter" any web page as if it were a room, and chat with other visitors. SamePlace relies on the jsjab javascript library for Mozilla, which allows connecting to a jabber server in the usual (i.e. non-HTTP) way. Comments and bug reports are welcome. Enjoy, Massimiliano
Re: [jdev] virtual hosting and certificate checking
Funnily enough, if we'd had naming in TLS from the start, there probably wouldn't even *be* STARTTLS since everyone would be using the better method. :-) I doubt that since the main reason STARTTLS is there is so that you can reuse the same port for both encrypted and unencrypted versions of a protocol not really so you can pass the desired hostname, thats just a side benefit of being able to start out unencrypted. Richard
Re: [jdev] virtual hosting and certificate checking
On Friday 03 March 2006 21:10, Justin Karneges wrote: > Hmm, there shouldn't be a need to introduce server names into TLS, which is > technically supposed to exist independently of TCP/IP. > > IMO, a better way would be to use RFC 2817, which allows upgrading a > plaintext HTTP connection to TLS dynamically. It works essentially the > same way as XMPP's "starttls". Sadly, no one actually uses this great > spec. I'm sure that some services still have a name outside of TCP/IP. Besides, it's only an extension, which does make a bit of sense since you would just choose not to use that extension in the case where you're not going over TCP/IP (analogous to an XMPP server choosing not to allow external auth if the connection is not going over TLS.) Funnily enough, if we'd had naming in TLS from the start, there probably wouldn't even *be* STARTTLS since everyone would be using the better method. :-) RFC 2817 is still neat though. Funny how web browsers, despite being the most used Internet app around, or so they say, are so slow to follow standards. We should have SRV for web browsers too, but hardly anyone implemented that too. TX -- Email: [EMAIL PROTECTED] Jabber ID: [EMAIL PROTECTED] Web site: http://trypticon.org/ GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F A62C B8C7 BC8B 037E EA73 pgpTrwM2LrARY.pgp Description: PGP signature
[jdev] [JEP-0114] Jabber Component Protocol question
Hi, I was just getting around to implementing JCP into the server, and realized that the server would need to treat a "component" different from a "user". The JCP spec also defines a new jabber:component namespace under which all the stanzas would be sent. IMO, it would be great for server implementors to have component connections being accepted on a different port instead of the default 5222. Also, if a new SRV record could be defined of type xmpp-component, components can look it up and establish connections to servers accordingly. We are already doing it for the jabber:client and jabber:server stream namespaces... why not for the jabber:component namespace? This way, the concerns can be separately and elegantly addressed. WDYAT? Regards, Vinod.
Re: [jdev] virtual hosting and certificate checking
On Fri, 3 Mar 2006, Justin Karneges wrote: > > IMO, a better way would be to use RFC 2817, which allows upgrading a plaintext > HTTP connection to TLS dynamically. It works essentially the same way as > XMPP's "starttls". Sadly, no one actually uses this great spec. I get the impression that that is because it's a pain to implement :-) e.g. http://coders.meta.net.nz/weblog/2005/03/25/server-name-indication-or-how-to-virtual-host-ssl/ I note that other protocols which have a starttls function - SMTP, IMAP, POP - don't have a mechanism outside TLS for indicating the server name. XMPP is unusual in this respect. RFC 3546 SNI has the advantage that it solves the problem for all protocols that use TLS, and in the context of HTTP it has MUCH lower latency than RFC 2817. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ HUMBER: WEST OR NORTHWEST 3 OR 4 INCREASING 5 OR 6. WINTRY SHOWERS. MAINLY GOOD.
Re: [jdev] virtual hosting and certificate checking
On Friday 03 March 2006 01:41, Tony Finch wrote: > On Fri, 3 Mar 2006, Jesus Cea wrote: > > In current TLS, client gives the host it is trying to connect, BEFORE > > negociating crypto. So if you are using a modern webserver and a modern > > browser, you can share the IP. > > > > I just don't remember if this feature is present in TLS 1.0 or in the > > current draft for next revision. > > This is an RFC 3546 extension to TLS 1.0 - the "server name indication". > It appears that this is not supported by OpenSSL but it is by GnuTLS. > "Modern browser" in this situation means released within the last few > months. Hmm, there shouldn't be a need to introduce server names into TLS, which is technically supposed to exist independently of TCP/IP. IMO, a better way would be to use RFC 2817, which allows upgrading a plaintext HTTP connection to TLS dynamically. It works essentially the same way as XMPP's "starttls". Sadly, no one actually uses this great spec. -Justin
Re: [jdev] virtual hosting and certificate checking
On Fri, 3 Mar 2006, Jesus Cea wrote: > > In current TLS, client gives the host it is trying to connect, BEFORE > negociating crypto. So if you are using a modern webserver and a modern > browser, you can share the IP. > > I just don't remember if this feature is present in TLS 1.0 or in the > current draft for next revision. This is an RFC 3546 extension to TLS 1.0 - the "server name indication". It appears that this is not supported by OpenSSL but it is by GnuTLS. "Modern browser" in this situation means released within the last few months. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ RATTRAY HEAD TO BERWICK ON TWEED: CYCLONIC 3 OR 4, OCCASIONALLY 5, BECOMING NORTH OR NORTHWEST 5 OR 6 DURING THIS EVENING AND OVERNIGHT. SCATTERED SNOW SHOWERS. GOOD FALLING POOR IN SHOWERS. MODERATE OR ROUGH.
Re: [jdev] virtual hosting and certificate checking
On 3/3/06, Hal Rottenberg <[EMAIL PROTECTED]> wrote: > On 3/2/06, Trejkaz <[EMAIL PROTECTED]> wrote: > > Jesus Cea wrote: > > > In current TLS, client gives the host it is trying to connect, BEFORE > > > negociating crypto. So if you are using a modern webserver and a modern > > > browser, you can share the IP. > > Now, that's awesome. However, I know for sure that the very latest > > release of Apache can't do it, so... > I do it right now on an older version. I asked Google briefly but couldn't find anything. Can you post a link to a HOWTO? -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
