Let servers advertise to clients that they are secure-preferred about ircv3-specifications HOT 42 CLOSED

To clarify, this is about letting servers advertise that they are secure preferred and that a conforming client MUST use secure transport connections in future. The server MAY still allow non-secure connections from non conforming clients. This is analagous to HSTS for HTTP http://tools.ietf.org/html/rfc6797

from ircv3-specifications.

@attilamolnar What about the SSL::port thingy that is in InspIRCd 2.0's RPL_ISUPPORT? I think that worked very well.

from ircv3-specifications.

👎 on the SSL= entry in RPL_ISUPPORT. This was removed in favour of STARTTLS in 2.2 due to how useless it is.

from ircv3-specifications.

I'd argue that STARTTLS is just as useless. I have yet to see a modern client support it.

from ircv3-specifications.

22.03.2014 20:20, TheTechman пишет:

I'd argue that STARTTLS is just as useless. I have yet to see a modern
client support it.

—
Reply to this email directly or view it on GitHub
#77 (comment).

KVIrc

from ircv3-specifications.

I think that's just about the only client that supports it. Others are libraries of some type.

from ircv3-specifications.

I'd argue that STARTTLS is just as useless. I have yet to see a modern client support it.

It is an optional extension in IRC 3.1, not mandatory. That said... I always hate this sort of argument because it's so... poisonous. There's nothing harmful in documenting a spec, and we can give it the appropriate severity level, so I am not even sure why this argument is being made here. The larger problem here is that IRC users do not understand why security is important yet, therefore they do not demand this stuff from their client vendors.

from ircv3-specifications.

Thinking on this a little further, I think a better approach is this: deprecate all plaintext IRC use altogether.

What this means is simple:

1. Client and Server vendors agree to drop very ominous warning messages in the short-term (IRC 3.2 - 3.3 cycles), about plaintext IRC being deprecated.
2. The warning message for clients would be displayed upon connection, a similar one would be sent to the user on connection by the IRCd, additionally a notice would be displayed when a plaintext listener is created in the ircd.conf.
3. The warning message would direct users to a page hosted by the IRCv3 working-group about how to connect to the IRCS ports. The page would push for users to use port 6697, but could be customized by the admin to link to an alternate page.
4. In the 3.4 cycle, we could create a new listener type which is still plaintext but redirects users to the page and then rejects them.

Thoughts?

from ircv3-specifications.

👍 I agree with this proposal.

from ircv3-specifications.

23.03.2014 06:08, William Pitcock пишет:

In the 3.4 cycle, we could create a new listener type which is still
plaintext but redirects users to the page and then rejects them.

I'm not sure anyone will deploy these listeners...

from ircv3-specifications.

Whilst I agree that warning about the dangers of unencrypted connections is a good idea I don't think that they are going away any time soon no matter how much we try to force it. We would be better off spending time educating users on why encryption is important.

from ircv3-specifications.

Just as not all websites offer https, not all irc servers will offer secure connections. There's nothing "deprecated" about it. But for those that do, they should have a way to ensure conforming clients use them.

This isn't about educating users, browsers have shown that's a fool's errand. It's about giving servers the chance to state a policy that protects their users automatically, with the help of conforming clients.

from ircv3-specifications.

I think it is better to do this using SRV RR's as described in #59 . The RR has to indicate priority and there is no reason why a server cannot give the _ircs._tcp or the possible _ircs._sctp RR's a higher priority than _irc._tcp:

Example implementation:
_ircs._sctp.argure.nl. NXDOMAIN
_ircs._tcp.argure.nl. 7200 IN SRV 0 5 194 ilum.argure.nl.
_ircs._tcp.argure.nl. 7200 IN SRV 1 5 6697 ilum.argure.nl.
_irc._tcp.argure.nl. 7200 IN SRV 2 5 994 ilum.argure.nl.
_irc._tcp.argure.nl. 7200 IN SRV 3 5 6667 ilum.argure.nl.

I strongly believe advertisement of support should be done out of band (for obvious security reasons) and the same applies to a lesser extent to protocol preferences.

from ircv3-specifications.

I don't see why can't we do both.

from ircv3-specifications.

Because that would be redundant, and moronic.

from ircv3-specifications.

Whilst I agree that warning about the dangers of unencrypted connections is a good idea I don't think that they are going away any time soon no matter how much we try to force it. We would be better off spending time educating users on why encryption is important.

The implication is that we would, as IRCd vendors, pledge to drop support for them at some point in the future.

from ircv3-specifications.

Just as not all websites offer https, not all irc servers will offer secure connections. There's nothing "deprecated" about it.

This argument is silly. Of course there's nothing deprecating it right now. We would have to write that. Stop being silly.

This isn't about educating users, browsers have shown that's a fool's errand. It's about giving servers the chance to state a policy that protects their users automatically, with the help of conforming clients.

On the other hand, really, there's browser extensions which make the browser prefer HTTPS always. That's an initial step to deprecating plaintext HTTP. We can do the same here. At the end of the day, is it not the goal of this work to get more people on IRCS vs IRC?

from ircv3-specifications.

I don't see plaintext IRC going away within the next 10 years, some browsers have been fighting for HTTPS everywhere but that still hasn't caused plaintext HTTP to be depreciated.

I think if we focused on the SRV RR's like @Argure suggested then we will lessen the use of plaintext IRC and it is a step towards depreciating it someday.

I don't want to see warnings about depreciating this because it's not going to do anything but annoy users.

from ircv3-specifications.

@Argure Er, my response was for

We would be better off spending time educating users on why encryption is important.

and

It's about giving servers the chance to state a policy that protects their users automatically, with the help of conforming clients.

from ircv3-specifications.

@Argure AFAIK, changing the priorities won't change which service is preferred. So if the priority is lower for _ircs, that doesn't mean a client will prefer _irc, since from the perspective of SRV records they're different services. That they're somewhat substitutable in this case doesn't make the general case one where that's the case.

from ircv3-specifications.

@Argure, I'm not sure that this is "obvious" to me:

I strongly believe advertisement of support should be done out of band (for obvious security reasons)

HSTS advertisement is in-band and seems like a much better-designed mechanism than relying on SRV records (which are in DNS and therefore easier to manipulate – via cache poisoning – than even the plaintext TCP connection for most attackers).

Also, the point of HSTS is to advertise a persistent preference for security, to reduce the time the plaintext intercept attack surface is available. Once a server has advertised HSTS, it persists for any client which has seen it until the HSTS max-age parameter. This is supposed to be set to a very long interval (at a minimum, let's say, until the expiration of the current certificate). If you tie this to an SRV record TTL instead, then the server administrator will either set short TTLs, (7200 as in your example) so they preserve the ability to change port numbers, or very long TTLs which will nail their hostname and port number to their security preferences.

I'm inclined to agree with @kaniini about deprecating plaintext IRC entirely. Connections should just be secure, end of story. Users don't need to be educated, because users aren't doing key management or verifying cryptographic signatures. They just say "irc.example.com please", and if that connection succeeds it should be understood to be as secure as is reasonable. The connection can fail because irc.example.com has misconfigured its DNS; users don't need to be educated about DNS. It can also fail because irc.example.com has misconfigured its TLS certificate. Users don't need to know about that, either; the connection can just fail.

Now, there's the question of allowing people to operate IRC servers without participating in the certificate authority cartel; it would be nice to have some option for clients to have a SSH-style model for trusting self-signed certificates upon connecting to a server.

from ircv3-specifications.

The connection can fail because irc.example.com has misconfigured its DNS; users don't need to be educated about DNS. It can also fail because irc.example.com has misconfigured its TLS certificate. Users don't need to know about that, either; the connection can just fail.

With an appropriate error message that distinguishes the cases, I hope. Nothing is more annoying than trying to fix a problem when the only non-misleading clues you have are that it exists. So "DNS lookup failed" should be distinct from "certificate is wrong", not least because the former is potentially caused by something the user can correct!

from ircv3-specifications.

@kythyria I think how exactly clients present this is up to them, but there's no security reason to discourage them from distinguishing and I wouldn't recommend that.

from ircv3-specifications.

I'd like to see this happening in 3.2 by means of a cap which if present would indicate the tls preference, staying true to the original proposal. While SRV records do the trick too the proposal is not ready for 3.2; moreover understanding and implemeting the whole concept for client authors is orders of magnitude harder than a secure-preferred[=<unixtime>] cap.

Thoughts?

from ircv3-specifications.

If you're just using secure-preferred to advertise, why add it as a CAP and not a token in the 005 numeric?

from ircv3-specifications.

Because CAP is before reg and the client must abort the registration if it adheres to secure-preferred and is on a plaintext connection.

from ircv3-specifications.

But because clients don't know if a server supports CAP or not they send all the commands, CAP, USER, NICK, and PASS if applicable before receiving the response to CAP. So you're leaking the same amount of user information by finishing the registration and looking at the 005 numeric as you are by terminating the connection as soon as CAP returns.

I still think a SSL=port1,port2,etc in the 005 numeric would be useful for this suggestion, it advertises the fact that it has SSL for clients that want to use it, and it also provides the ports that SSL is enabled on so clients can auto-reconnect on that port.

from ircv3-specifications.

It's worth reiterating that this is a policy setting, not a user preference. This allows servers to force compliant clients to reconnect on SSL, not just advertise that SSL is available. Hence the expiry date.

from ircv3-specifications.

@shawn-smith The idea is that the client aborts the connection instead of sending CAP END (which means the reg does not finish) if both parties support this.

from ircv3-specifications.

@attilamolnar what is that time after = ?

from ircv3-specifications.

@DarthGandalf It is the time until the server making the advertisement will remain committed to supporting tls, meaning that e.g. the client may blindly send STARTTLS until that time [1]. In other words, it is when the advertisement expires.

[1]: whether we want to use STARTTLS here or something else is up for discussion

from ircv3-specifications.

The way this should work is that once the client sees the advertisement it should try to establish a secure connection and confirm the advertisement. This is the way how it is done in HSTS (link below) because otherwise a one-time MITM attacker can cause denial of service for an arbitrary long time if the server does not support TLS and the attacker forges an advertisement saying that it does, which causes the client to fail all future connections until the advertisement expires.

@jwheare does this correlate with you have on mind?

Reference: https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security#Enabling_Strict_Transport_Security

from ircv3-specifications.

Sounds good. But in HSTS it's not "unix time", but number of seconds since now.

from ircv3-specifications.

Hmm, actually, a key point about HSTS is that browsers will ignore any STS headers sent over HTTP because they could be put there by a MITM attacker. So the standard pattern is for a web site to force a redirect to HTTPS, and then set the header. Not sure how this would work with IRC.

Maybe an equivalent to the "Location" header is needed.

There's 010 RPL_BOUNCE/RPL_REDIR, but that doesn't seem to support specifying a secure connection.
010 <hostname> <port> :<info>

secure-preferred=seconds also doesn't help in any way with ports, while the SSL=port1,port2,etc in 005 would.

I think for this to work properly you'd need a CAP to support an extra parameter to 010 for the secure bit, then send 010 <hostname> <port> true :<info> after CAP negotiation, then after a secure reconnect, send the secure-preferred=seconds CAP/005. I don't know if secure-preferred even makes sense as a CAP. Is the server going to behave differently if it knows the client acknowledges secure-preferred? Then again, I guess adding more stuff to 005 is frowned upon.

Of course, this method still exposes you to an initial MITM threat on the first non-secure connection before a redirect, but that can be solved with preload lists in clients. In browsers these are based on the client vendor checking for a valid HSTS header:

From https://blog.mozilla.org/security/2012/11/01/preloading-hsts/

Our “preload list” has been seeded with entries from Chrome’s list of a similar function. To build our preload list, a request is sent to every host with ‘mode: “force-https”‘ on Chrome’s list. Only if a host responds with a valid HSTS header with an appropriately large max-age value (currently greater than or equal to 10886400, which is eighteen weeks) do we include it in our list

from ircv3-specifications.

It's worth reading that whole post, for more details on how they handle sites that choose to revert to non-HSTS status, with max-age=0 headers resulting in knockout entries.

from ircv3-specifications.

So the standard pattern is for a web site to force a redirect to HTTPS, and then set the header. Not sure how this would work with IRC.
There's 010 RPL_BOUNCE/RPL_REDIR, but that doesn't seem to support specifying a secure connection.

I don't think we should pull that numeric into this. We can define how clients should behave if they see this advertisement, we can tell them that the correct behavior is reconnection on a TLS port (if TLS ports are listed in the advertisement somehow) or using STARTTLS on the same port as before.

secure-preferred=seconds also doesn't help in any way with ports, while the SSL=port1,port2,etc in 005 would.

We can advertise ports using secure-preferred in a similiar way:
secure-preferred=<seconds>;<port1>[,<port2>...]

[...]
Then again, I guess adding more stuff to 005 is frowned upon.

The main problem I see with 005 is not "adding more stuff" (I acknowledge that some might not like adding anything in there), but the problem is that the 005 comes after the registration completes.
What this means is that for example the following events would occur for conforming secure-preferred clients before they reconnect using a secure transport:

• Remote servers are notified about the connecting client
• Log entries are generated, perhaps on all servers
• Opers subscribed to connect server notices receive "client X is connecting"
• The server might even autojoin the client to a channel

Then the events would occur once again after the client has reconnected.

Comparison pre-reg (in CAP) vs. post-reg (in 005). In both examples I'm going to use STARTTLS, but the principle is the same; we could use a different port if we wanted to in both cases.

First see how it would work pre-reg:

Client: (connects non-securely)

Client: CAP LS
Client: NICK Attila
Client: USER attila 0 0 :Attila
Server: :example.org CAP * LS :secure-preferred
Client: (Let's see if you are serious about that... *disconnects*)

In this case, none of the above listed events happen.

Client: (reconnects)
Client: STARTTLS
Server :example.org 670 * :STARTTLS successful, please start the TLS handshake now

Connection is upgraded to TLS successfully.

Client: CAP LS
Client: NICK Attila
Client: USER attila 0 0 :Attila
Server: :example.org CAP * LS :secure-preferred
Client: (The server is indeed serious; remembers secure preferred for the server)
Client: CAP END
Server: :example.org 001 Attila :Welcome to the SUPER IRC Network [email protected]
Client: (Starts usual IRC activity)

At this point, the server considers the client registered, does everything applicable I listed above. It sends the 005 numeric, MOTD, introduces the client to remote servers and opers, etc.

Contrast this to if the advertisement was made in 005, for this we will call the imaginary 005 token SECUREPREFERRED.

Client: (connects non-securely)

Client: CAP LS
Client: NICK Attila
Client: USER attila 0 0 :Attila
Server: :example.org CAP * LS :multi-prefix
Client: CAP REQ :multi-prefix
Client: CAP END
Server: :example.org CAP * ACK :multi-prefix
Server: :example.org 001 Attila :Welcome to the SUPER IRC Network [email protected]
Server: :example.org 002 Attila :same as usual
Server: :example.org 003 Attila :same as usual
Server: :example.org 004 Attila :same as usual
Server: :example.org 005 Attila :SECUREPREFERRED
Client: (Let's see if you are serious about that... *disconnects*)

At this point, the server has already done everything applicable I outlined above. Even if the client disconnects immediately after seeing 005 token, the MOTD, etc. was already sent to the client (the client closing the connection before processing them doesn't change that).
As shown above, the client may even be autojoined to one or more channels which means other users are going to receive JOIN/QUIT.

Client: (reconnects)
Client: STARTTLS
Server :example.org 670 * :STARTTLS successful, please start the TLS handshake now

Connection is upgraded to TLS successfully.

Client: CAP LS
Client: NICK Attila
Client: USER attila 0 0 :Attila
Server: CAP * LS :multi-prefix
Client: CAP REQ :multi-prefix
Client: CAP END
Server: CAP * ACK :multi-prefix
Server: :example.org 001 Attila :Welcome to the SUPER IRC Network [email protected]
Server: :example.org 002 Attila :same as usual
Server: :example.org 003 Attila :same as usual
Server: :example.org 004 Attila :same as usual
Server: :example.org 005 Attila :SECUREPREFERRED
Client: (The server is indeed serious; remembers secure preferred for the server and starts usual IRC activity)

Now the client has registered for the second time. Here's what an oper could see in their client:

-irc.example.com- Client [email protected] has connected to server example.org
-irc.example.com- Client [email protected] has quit (Connection closed)
-irc.example.com- Client [email protected] has connected to server example.org

I hope you can understand now why I favor this occuring pre-reg, not 005.

from ircv3-specifications.

Yup, satisfied that 005 is inappropriate.

If we're really modelling this on HSTS, the CAP should probably be called strict-transport-security not secure-preferred, it's not a preference, it's a strict rule.

I'd also favour named rather than positional arguments, e.g. strict-transport-security=max-age:<seconds>;ports:6697,7000

(Or maybe other delimiters, I guess : isn't allowed)

Worth noting also that the client should only reconnect with a STARTTLS upgrade if the server advertises the tls CAP and there are no secure ports advertised with strict-transport-security, otherwise a secure connection can be established from the beginning, with no upgrade required.

from ircv3-specifications.

I'm with @kaniini here, I think plaintext IRC should be deprecated, is to be considered harmful, and should be a thing of the past.

from ircv3-specifications.

@wilhelmy I agree, how about secure-by-default?

from ircv3-specifications.

"Secure by default" is a good sounding phrase but conveys none of the actions to take to achieve security. STS with preload lists are one step in that direction, it provides a working upgrade path. The next step could be restricting new features to secure connections for example. Doing only the latter requires users to reconfigure all servers they use manually instead of the client doing it.

from ircv3-specifications.

Maybe extend RPL_REDIR(010 numeric) a little to support saying to clients to direct to server/port and somehow say that it's an SSL port.

*** RPL_REDIR ***/ ":%s %d :Please use this SSL Server/Port instead" perhaps?

Or simply just don't listen on a plaintext port. Not everything needs to be over-engineered ;)

from ircv3-specifications.

The specification covering the basics has been merged. I have opened new issues for the next TODO items.

from ircv3-specifications.