9front - general discussion about 9front
 help / color / mirror / Atom feed
* [9front] [patch] devtls updates
@ 2021-05-30 15:05 fulton
  2021-05-31  0:03 ` Lyndon Nerenberg (VE7TFX/VE6BBM)
  2021-05-31 11:45 ` cinap_lenrek
  0 siblings, 2 replies; 8+ messages in thread
From: fulton @ 2021-05-30 15:05 UTC (permalink / raw)
  To: 9front

Remove broken ciphers (3des, rc4), md5 from devtls add sha384, sha512
support to devtls.  Document bad ciphers and hash functions as bad.

Patch: http://okturing.com/src/11150/body
--
Fulton



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] [patch] devtls updates
  2021-05-30 15:05 [9front] [patch] devtls updates fulton
@ 2021-05-31  0:03 ` Lyndon Nerenberg (VE7TFX/VE6BBM)
  2021-05-31 15:37   ` ori
  2021-05-31 11:45 ` cinap_lenrek
  1 sibling, 1 reply; 8+ messages in thread
From: Lyndon Nerenberg (VE7TFX/VE6BBM) @ 2021-05-31  0:03 UTC (permalink / raw)
  To: 9front, fulton

There's a lot of old hardware out there that only speaks these
obsolete methods and which will never see an upgrade.  I have a
half-dozen switches in use at home that fit this category.  Rather
than completely gut this support, it would be better to turn it
off in the default configuration, but leave a switch that can be
used to enable the obsolete cruft only when required.

This is how OpenBSD's SSH handles obsolate ciphers.  Disabled by
default, but I can request them when needed.  And you might be
surprised at how much recent vintage network gear in our data centre
needs those old ciphers :-(

Most SSL libraries work the same way, albeit often with bad default
settings and very awkward configuration schemes.

--lyndon

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] [patch] devtls updates
  2021-05-30 15:05 [9front] [patch] devtls updates fulton
  2021-05-31  0:03 ` Lyndon Nerenberg (VE7TFX/VE6BBM)
@ 2021-05-31 11:45 ` cinap_lenrek
  2021-05-31 16:16   ` fulton
  1 sibling, 1 reply; 8+ messages in thread
From: cinap_lenrek @ 2021-05-31 11:45 UTC (permalink / raw)
  To: 9front

that patch is stupid.

who the hell uses sha512 as a digest? do not add more of this crap, it is OVER.

the issue with the cipher+digest construction was that the padding schemes
and the order of encryption and authentication turned out to have issues.

modern tls cipher suits use aead ciphers where authentication and encryption are
done together and the whole construction has been validated as a whole.

such as: chacha20-poly1305 and aes-gcm.

which we all support and it will get negotiated when avalable over the classic
cypher+digest tls suits.

adding more digest algorithms in devtls doesnt do anything. what matters is what
tlshand.c negotiates and it has a curated list of cipher suits. in the end
the server has the final say what cipher is picked.

and in comparsion to mozilla we never had these downgrade attack issues
because we did not just reconnect and try with a older version.

--
cinap

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] [patch] devtls updates
  2021-05-31  0:03 ` Lyndon Nerenberg (VE7TFX/VE6BBM)
@ 2021-05-31 15:37   ` ori
  2021-05-31 22:46     ` Lyndon Nerenberg (VE7TFX/VE6BBM)
  0 siblings, 1 reply; 8+ messages in thread
From: ori @ 2021-05-31 15:37 UTC (permalink / raw)
  To: 9front

Quoth Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca>:
> 
> This is how OpenBSD's SSH handles obsolate ciphers.  Disabled by
> default, but I can request them when needed.  And you might be
> surprised at how much recent vintage network gear in our data centre
> needs those old ciphers :-(

Do you have specifics? I'd like to at least
try to remove the blatantly broken stuff.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] [patch] devtls updates
  2021-05-31 11:45 ` cinap_lenrek
@ 2021-05-31 16:16   ` fulton
  0 siblings, 0 replies; 8+ messages in thread
From: fulton @ 2021-05-31 16:16 UTC (permalink / raw)
  To: 9front

Quoth cinap_lenrek@felloff.net:
> that patch is stupid.

Understood

--
Fulton fulton.software!fulton

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] [patch] devtls updates
  2021-05-31 15:37   ` ori
@ 2021-05-31 22:46     ` Lyndon Nerenberg (VE7TFX/VE6BBM)
  2021-06-02  0:38       ` ori
  0 siblings, 1 reply; 8+ messages in thread
From: Lyndon Nerenberg (VE7TFX/VE6BBM) @ 2021-05-31 22:46 UTC (permalink / raw)
  To: 9front, ori

> Do you have specifics? I'd like to at least
> try to remove the blatantly broken stuff.

Just off the top of my head, SSH needs aes128-cbc in order to talk
to our HP 5500s.  As of OpenBSD 6.7 or so I have to explicitly
enable that on the client side, otherwise it won't negotiate.  Our
budget 3Com switches in the office are in the same boat (I can't
connect to them from home so I can't give you a model number
off-hand).  The latter also suffer from ancient TLS implementations
that require frobbing of hashes and ciphers, but again, I can't get
to them from here to look up the specifics.

In a nutshell I would preserve the functionality needed to wind back
to TLS 1.0, but disable negotiating anything that isn't required
for >= TLS 1.2 unless explicitly asked for by the user.

--lyndon

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] [patch] devtls updates
  2021-05-31 22:46     ` Lyndon Nerenberg (VE7TFX/VE6BBM)
@ 2021-06-02  0:38       ` ori
  2021-06-02  4:30         ` Lyndon Nerenberg (VE7TFX/VE6BBM)
  0 siblings, 1 reply; 8+ messages in thread
From: ori @ 2021-06-02  0:38 UTC (permalink / raw)
  To: 9front, ori

Quoth Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca>:
> > Do you have specifics? I'd like to at least
> > try to remove the blatantly broken stuff.
> 
> Just off the top of my head, SSH needs aes128-cbc in order to talk
> to our HP 5500s.  As of OpenBSD 6.7 or so I have to explicitly
> enable that on the client side, otherwise it won't negotiate.  Our
> budget 3Com switches in the office are in the same boat (I can't
> connect to them from home so I can't give you a model number
> off-hand).  The latter also suffer from ancient TLS implementations
> that require frobbing of hashes and ciphers, but again, I can't get
> to them from here to look up the specifics.
> 
> In a nutshell I would preserve the functionality needed to wind back
> to TLS 1.0, but disable negotiating anything that isn't required
> for >= TLS 1.2 unless explicitly asked for by the user.
> 
> --lyndon

ssh doesn't use devssl or devtls, so that's
not really relevant to this patch set.

For tls, I'd be ok with keeping specific
obsolete ciphers around if there are
devices that need it, but rc4 is well
past deprecated into kill it with fire
territory:

	https://datatracker.ietf.org/doc/html/rfc7465

but for that, we need to decide what we
do with cpu, exportfs, and oexportfs.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] [patch] devtls updates
  2021-06-02  0:38       ` ori
@ 2021-06-02  4:30         ` Lyndon Nerenberg (VE7TFX/VE6BBM)
  0 siblings, 0 replies; 8+ messages in thread
From: Lyndon Nerenberg (VE7TFX/VE6BBM) @ 2021-06-02  4:30 UTC (permalink / raw)
  To: 9front, ori

> For tls, I'd be ok with keeping specific
> obsolete ciphers around if there are
> devices that need it

You could overload the encalgs and hashalgs files to allow writes
of '-hashalg' to remove an entry from the supported list.  In fact,
I think it might be useful to have a general write interface on
those files where +alg adds to the list, -alg removes from the list,
and any other write specifies an absolute list of algs to turn on.
This would give the host owner fine grained control over what TLS
would be willing to do (and, of course, allow them to break things
in spectacular fashion).  Removing write perms on either of the
files would permanently make the underlying alg list immutable.

In conjunction with that, add a '#aX' aname (that's a literal 'X'
character, not a place holder) that references a TLS stack instance
with all the obsolete algs available, but not necessarily enabled.
Running 'bind -a '#aX' /net' would present, e.g., a /net/tls.insecure
directory tree.  Then things like cpu and oexportfs would have to
bind /net/tls.insecure over /net/tls to get access to the old cruft.

It would be good to have a switch that disabled binding the '#aX'
device completely.  That would allow the host owner to easily
prevent the old stuff from ever being used.  Once disabled, it
can't be turned on again.

Anyway, that's just something that sprang to mind when I read the
question.  Take it with the full five minutes thought I've given it.

--lyndon

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2021-06-02 14:36 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-30 15:05 [9front] [patch] devtls updates fulton
2021-05-31  0:03 ` Lyndon Nerenberg (VE7TFX/VE6BBM)
2021-05-31 15:37   ` ori
2021-05-31 22:46     ` Lyndon Nerenberg (VE7TFX/VE6BBM)
2021-06-02  0:38       ` ori
2021-06-02  4:30         ` Lyndon Nerenberg (VE7TFX/VE6BBM)
2021-05-31 11:45 ` cinap_lenrek
2021-05-31 16:16   ` fulton

9front - general discussion about 9front

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/9front

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 9front 9front/ http://inbox.vuxu.org/9front \
		9front@9front.org
	public-inbox-index 9front

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.9front


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git