From: Olga Kornievskaia <aglo@umich.edu>
To: Hannes Reinecke <hare@suse.de>
Cc: Chuck Lever III <chuck.lever@oracle.com>,
kernel-tls-handshake <kernel-tls-handshake@lists.linux.dev>
Subject: Re: ktls-utils PR needs review
Date: Tue, 23 Apr 2024 14:52:00 -0400 [thread overview]
Message-ID: <CAN-5tyE6GAB7XTDGcbW-7EO_xiL67KjoFQsnEA4_4vvQnPUgBg@mail.gmail.com> (raw)
In-Reply-To: <ac997b67-ad82-4e98-81fd-ac01ea13159c@suse.de>
On Tue, Apr 23, 2024 at 2:53 AM Hannes Reinecke <hare@suse.de> wrote:
>
> On 4/22/24 17:59, Chuck Lever III wrote:
> >
> >
> >> On Apr 22, 2024, at 11:55 AM, Olga Kornievskaia <aglo@umich.edu> wrote:
> >>
> >> On Mon, Apr 22, 2024 at 11:16 AM Chuck Lever III <chuck.lever@oracle.com> wrote:
> >>>
> >>> https://github.com/oracle/ktls-utils/pull/54
> >>>
> >>> I seem to recall a similar command line option that we
> >>> removed because it was insecure.
> >>>
> >>> At the very least this needs a man page update, but I'm
> >>> not convinced this setting should be allowed.
> >>
> >> I agree.
> >>
> >> Can we have this only available under some strict usage? Like it can
> >> only work started in the foreground (with some -d flag) and it’ll only
> >> run for 10mins and then it will exit… something like that would
> >> prevent somebody from using it on a permanent basis.
> >
> > Interesting idea, that would ensure it could be used only
> > for debugging.
> >
> > Reuben closed the PR because he is having trouble with the
> > OCA signing. But you could add that suggestion to the PR
> > and see what he thinks.
> >
> I am not sure if I agree with the argument; after all, openssl and
> gnutls both have a standard option disabling the certificate check, too.
> And you might be needing it under certain circumstances (Self-signed
> certificates? Initial deployment?).
But do browsers have an option to not verify certificates for https? I
think we need to look for real world applications that use TLS and see
if they have options to do no verification.
> What we could do is to delegate the functionality to be command-line
> only (and not via the config file). That way it'll be immediately
> obvious that this option is enabled, and we would avoid proliferation
> via a forgotten config option setting.
>
> Cheers,
>
> Hannes
> --
> Dr. Hannes Reinecke Kernel Storage Architect
> hare@suse.de +49 911 74053 688
> SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
> HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
>
prev parent reply other threads:[~2024-04-23 18:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-22 15:16 ktls-utils PR needs review Chuck Lever III
2024-04-22 15:55 ` Olga Kornievskaia
2024-04-22 15:59 ` Chuck Lever III
2024-04-23 6:53 ` Hannes Reinecke
2024-04-23 13:21 ` Chuck Lever III
2024-04-23 18:52 ` Olga Kornievskaia [this message]
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=CAN-5tyE6GAB7XTDGcbW-7EO_xiL67KjoFQsnEA4_4vvQnPUgBg@mail.gmail.com \
--to=aglo@umich.edu \
--cc=chuck.lever@oracle.com \
--cc=hare@suse.de \
--cc=kernel-tls-handshake@lists.linux.dev \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).