9front - general discussion about 9front
 help / color / mirror / Atom feed
From: "Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca>
To: 9front@9front.org, ori@eigenstate.org
Subject: Re: [9front] [patch] devtls updates
Date: Tue, 01 Jun 2021 21:30:33 -0700
Message-ID: <0322ce98856002de@orthanc.ca> (raw)
In-Reply-To: <E88E56B2AA634413D52129EC46917209@eigenstate.org>

> 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

  reply	other threads:[~2021-06-02 14:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-30 15:05 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) [this message]
2021-05-31 11:45 ` cinap_lenrek
2021-05-31 16:16   ` fulton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0322ce98856002de@orthanc.ca \
    --to=lyndon@orthanc.ca \
    --cc=9front@9front.org \
    --cc=ori@eigenstate.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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