OpenSSH HPN

[Dag-Erling Smørgrav]

Some of you may have noticed that OpenSSH in base is lagging far behind
the upstream code.

The main reason for this is the burden of maintaining the HPN patches.
They are extensive, very intrusive, and touch parts of the OpenSSH code
that change significantly in every release. Since they are not
regularly updated, I have to choose between trying to resolve the
conflicts myself (hoping I don't break anything) or waiting for them to
catch up and then figuring out how to apply the new version.

Therefore, I would like to remove the HPN patches from base and refer
anyone who really needs them to the openssh-portable port, which has
them as a default option. I would also like to remove the NONE cipher
patch, which is also available in the port (off by default, just like in
base).

DES
--
Dag-Erling Smørgrav - d...@des.no
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

[Kubilay Kocak]

On 10/11/2015 8:42 PM, Dag-Erling Smørgrav wrote:
> Some of you may have noticed that OpenSSH in base is lagging far behind
> the upstream code.
>
> The main reason for this is the burden of maintaining the HPN patches.
> They are extensive, very intrusive, and touch parts of the OpenSSH code
> that change significantly in every release. Since they are not
> regularly updated, I have to choose between trying to resolve the
> conflicts myself (hoping I don't break anything) or waiting for them to
> catch up and then figuring out how to apply the new version.
>
> Therefore, I would like to remove the HPN patches from base and refer
> anyone who really needs them to the openssh-portable port, which has
> them as a default option. I would also like to remove the NONE cipher
> patch, which is also available in the port (off by default, just like in
> base).
>
> DES
>

I for one, support our new consistent-with-upstream,
improved-productivity and lower-risk-for-regressions-in-base overlords.

/koobs

[Willem Jan Withagen]

On 10-11-2015 10:42, Dag-Erling Smørgrav wrote:
> Some of you may have noticed that OpenSSH in base is lagging far behind
> the upstream code.
>
> The main reason for this is the burden of maintaining the HPN patches.
> They are extensive, very intrusive, and touch parts of the OpenSSH code
> that change significantly in every release. Since they are not
> regularly updated, I have to choose between trying to resolve the
> conflicts myself (hoping I don't break anything) or waiting for them to
> catch up and then figuring out how to apply the new version.
>
> Therefore, I would like to remove the HPN patches from base and refer
> anyone who really needs them to the openssh-portable port, which has
> them as a default option. I would also like to remove the NONE cipher
> patch, which is also available in the port (off by default, just like in
> base).

Hi Des,

I know I've installed the ports once to see if, and how I would be able
to add more IP-address infor to some of the warnings and errors. And
then to get thos errors recognised by tools like sshguard and fail2ban.

Only to find out that the code in that area in ports is completely
different from what is in base. And submitting "patches" for that, even
upstream, would be faily useless. So I understand the trouble you might
have in getting other stuff in as well

Getting the base version more inline with ports would be a real good thing.

I guess you need to manage the fallout that there is going to be from
those that expect HPN to be in base, and now suffer preformance issues.

--WjW

[Dag-Erling Smørgrav]

Willem Jan Withagen <w...@digiware.nl> writes:
> I know I've installed the ports once to see if, and how I would be
> able to add more IP-address infor to some of the warnings and
> errors. And then to get thos errors recognised by tools like sshguard
> and fail2ban.

Do you mean logging IP addresses instead of hostnames? Just turn off
UseDNS. It is off by default since 6.8.

If you mean adding IP addresses or hostnames to messages that don't
already have them, try suggesting it on the openssh-portable mailing
list (openssh-...@mindrot.org).

DES
--
Dag-Erling Smørgrav - d...@des.no

[Bob Bishop]

Hi,

> On 10 Nov 2015, at 09:42, Dag-Erling Smørgrav <d...@des.no> wrote:
>
> […]

>
> Therefore, I would like to remove the HPN patches from base and refer
> anyone who really needs them to the openssh-portable port, which has
> them as a default option. I would also like to remove the NONE cipher
> patch, which is also available in the port (off by default, just like in
> base).

Can’t argue with that. Is removing HPN going to impact the performance of tunnelled X connexions?

> DES
> --
> Dag-Erling Smørgrav - d...@des.no
> _______________________________________________

> freebsd...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

--
Bob Bishop
r...@gid.co.uk

[Willem Jan Withagen]

On 10-11-2015 11:55, Dag-Erling Smørgrav wrote:
> Willem Jan Withagen <w...@digiware.nl> writes:
>> I know I've installed the ports once to see if, and how I would be
>> able to add more IP-address infor to some of the warnings and
>> errors. And then to get thos errors recognised by tools like sshguard
>> and fail2ban.
>
> Do you mean logging IP addresses instead of hostnames? Just turn off
> UseDNS. It is off by default since 6.8.

No not really....
Digging in my logfiles .... , and its things like:
sshd[84942]: Disconnecting: Too many authentication failures [preauth]

So errors/warnings without IP-nr.

And I think I fixed it on one server to also write:
error: maximum authentication attempts exceeded for root from
173.254.203.88 port 1042 ssh2 [preauth]

Which when I found out that upstreaming patches from base will be hard,
because the whole logging in the ports version is totally different.

> If you mean adding IP addresses or hostnames to messages that don't
> already have them, try suggesting it on the openssh-portable mailing
> list (openssh-...@mindrot.org).

Are they still willing to accept changes to the old version that is
currently in base?

--WjW

[Dag-Erling Smørgrav]

Willem Jan Withagen <w...@digiware.nl> writes:
> Digging in my logfiles .... , and its things like:
> sshd[84942]: Disconnecting: Too many authentication failures [preauth]
>
> So errors/warnings without IP-nr.
>
> And I think I fixed it on one server to also write:
> error: maximum authentication attempts exceeded for root from
> 173.254.203.88 port 1042 ssh2 [preauth]

fail2ban should catch both of these since sshd will print a message for
each failed authentication attempt before it prints a message about
reaching the limit.

> Are they still willing to accept changes to the old version that is
> currently in base?

No, why would they do that?

DES
--
Dag-Erling Smørgrav - d...@des.no

[Dag-Erling Smørgrav]

Bob Bishop <r...@gid.co.uk> writes:
> Is removing HPN going to impact the performance of tunnelled X
> connexions?

I don't think so. It mostly affects the performance of long
unidirectional streams (file transfers) whereas the X protocol, as far
as I know, is a bidirectional exchange of relatively short messages. It
may make a difference for applications that transfer large textures...
I don't really know enough about the X protocol to say for certain, but
I am typing this in Emacs over a non-HPN SSH connection, and I regularly
tunnel Firefox between the same two machines (RHEL 7 desktop at work and
FreeBSD 10 desktop at home).

DES
--
Dag-Erling Smørgrav - d...@des.no
_______________________________________________

[Willem Jan Withagen]

On 10-11-2015 12:11, Dag-Erling Smørgrav wrote:
> Willem Jan Withagen <w...@digiware.nl> writes:
>> Digging in my logfiles .... , and its things like:
>> sshd[84942]: Disconnecting: Too many authentication failures [preauth]
>>
>> So errors/warnings without IP-nr.
>>
>> And I think I fixed it on one server to also write:
>> error: maximum authentication attempts exceeded for root from
>> 173.254.203.88 port 1042 ssh2 [preauth]
>
> fail2ban should catch both of these since sshd will print a message for
> each failed authentication attempt before it prints a message about
> reaching the limit.

It's already too long to remember the full facts, but when I was looking
at the parser in sshguard, I think I noticed that certain accesses
weren't logged and added some more logging rules to catch those.

What I still have lingering is this snippet:
Index: crypto/openssh/packet.c
===================================================================
--- crypto/openssh/packet.c (revision 289060)
+++ crypto/openssh/packet.c (working copy)
@@ -1128,8 +1128,10 @@
logit("Connection closed by %.200s",
get_remote_ipaddr());
cleanup_exit(255);
}
- if (len < 0)
+ if (len < 0) {
+ logit("Read from socket failed: %.200s",
get_remote_ipaddr());
fatal("Read from socket failed: %.100s",
strerror(errno));
+ }
/* Append it to the buffer. */
packet_process_incoming(buf, len);
}

But like I said: The code I found at openssh was so totally different
that I did not continued this track, but chose to start running openssh
from ports. Which does not generate warnings I have questions about the
originating ip-nr.

>> Are they still willing to accept changes to the old version that is
>> currently in base?
>
> No, why would they do that?

Exactly my question....
I guess I misinterpreted your suggestion on upstreaming patches.

--WjW

[Dag-Erling Smørgrav]

Willem Jan Withagen <w...@digiware.nl> writes:

> "Dag-Erling Smørgrav" <d...@des.no> writes:
> > Willem Jan Withagen <w...@digiware.nl> writes:
> > > Are they still willing to accept changes to the old version that
> > > is currently in base?
> > No, why would they do that?
> Exactly my question.... I guess I misinterpreted your suggestion on
> upstreaming patches.

I didn't suggest submitting patches, I suggested submitting a feature
request. Damien is generally pretty open to suggestions.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Slawa Olhovchenkov]

On Tue, Nov 10, 2015 at 10:42:49AM +0100, Dag-Erling Smørgrav wrote:

> Some of you may have noticed that OpenSSH in base is lagging far behind
> the upstream code.
>
> The main reason for this is the burden of maintaining the HPN patches.
> They are extensive, very intrusive, and touch parts of the OpenSSH code
> that change significantly in every release. Since they are not
> regularly updated, I have to choose between trying to resolve the
> conflicts myself (hoping I don't break anything) or waiting for them to
> catch up and then figuring out how to apply the new version.
>
> Therefore, I would like to remove the HPN patches from base and refer
> anyone who really needs them to the openssh-portable port, which has
> them as a default option. I would also like to remove the NONE cipher
> patch, which is also available in the port (off by default, just like in
> base).

I am plan to use NONE and HPN for bulk transfer, but don't see
performance improvement, in both cases I see only 500Mbit/s.

[Mark Felder]

I honestly think everyone would be better served by porting blacklistd
from NetBSD than trying to increase verbosity for log files.


--
Mark Felder
ports-secteam member
fe...@FreeBSD.org

[Miroslav Lachman]

Mark Felder wrote on 11/10/2015 17:02:

[...]

>> But like I said: The code I found at openssh was so totally different
>> that I did not continued this track, but chose to start running openssh
>> from ports. Which does not generate warnings I have questions about the
>> originating ip-nr.
>>
>>>> Are they still willing to accept changes to the old version that is
>>>> currently in base?
>>>
>>> No, why would they do that?
>>
>> Exactly my question....
>> I guess I misinterpreted your suggestion on upstreaming patches.
>>
>> --WjW
>>
>
> I honestly think everyone would be better served by porting blacklistd
> from NetBSD than trying to increase verbosity for log files.

I didn't know blacklistd. It seems very interesting. It would be nice if
somebody will port it to FreeBSD.

Miroslav Lachman

[John-Mark Gurney]

Dag-Erling Smrgrav wrote this message on Tue, Nov 10, 2015 at 10:42 +0100:
> Therefore, I would like to remove the HPN patches from base and refer
> anyone who really needs them to the openssh-portable port, which has
> them as a default option. I would also like to remove the NONE cipher
> patch, which is also available in the port (off by default, just like in
> base).

My vote is to remove the HPN patches. First, the NONE cipher made more
sense back when we didn't have AES-NI widely available, and you were
seriously limited by it's performance. Now we have both aes-gcm and
chacha-poly which it's performance should be more than acceptable for
today's uses (i.e. cipher performance is 2GB/sec+).

Second, I did some testing recently due to a thread on -net, and I
found no significant (not run statistically though) difference in
performance between in HEAD ssh and OpenSSH 7.1p1. I started a wiki
page to talk about this:
https://wiki.freebsd.org/SSHPerf

Feel free to add to the page any more info.

There are other apparent issues w/ ssh that keeps it's performance low
on high latency links, but I haven't spend the time to figure out what
they are, but in my testing HPN did not increase performance to make
use of the fat but high latency link.

So, if it's not increasing performance and making us fall behind, why
bother with the trouble of keeping the patch?

If someone is willing to spend the time doing benchmarks, and prove
that the HPN patches do make a difference, I'm willing to work with
them to figure out why my tests didn't work and change my vote. I
also believe that the defaults should be enough, if you have to tune
or enable features, then you can install from ports or compile yourself.

--
John-Mark Gurney Voice: +1 415 225 5579

"All that I will do, has been done, All that I have, has not."

[Michael Sinatra]

On 11/10/15 1:42 AM, Dag-Erling Smørgrav wrote:
> Some of you may have noticed that OpenSSH in base is lagging far behind
> the upstream code.
>
> The main reason for this is the burden of maintaining the HPN patches.
> They are extensive, very intrusive, and touch parts of the OpenSSH code
> that change significantly in every release. Since they are not
> regularly updated, I have to choose between trying to resolve the
> conflicts myself (hoping I don't break anything) or waiting for them to
> catch up and then figuring out how to apply the new version.
>
> Therefore, I would like to remove the HPN patches from base and refer
> anyone who really needs them to the openssh-portable port, which has
> them as a default option. I would also like to remove the NONE cipher
> patch, which is also available in the port (off by default, just like in
> base).

My current employer is a big proponent of HPN (see
http://fasterdata.es.net/data-transfer-tools/scp-and-sftp/). However, I
agree that the difficulty of patching to the changing upstream is
significant. Frankly, I am quite impressed that you have been able to
keep up with it for this long.

I would be more than happy if the HPN patches continued to be in the
port version and base were able to keep up with the upstream by removing
the HPN dependency. There will be some places where we will notice the
difference in performance; in those cases we will install the
HPN-patched port.

michael

[John-Mark Gurney]

Bryan Drewery wrote this message on Tue, Nov 10, 2015 at 16:32 -0800:

> On 11/10/15 9:52 AM, John-Mark Gurney wrote:
> > My vote is to remove the HPN patches. First, the NONE cipher made more
> > sense back when we didn't have AES-NI widely available, and you were
> > seriously limited by it's performance. Now we have both aes-gcm and
> > chacha-poly which it's performance should be more than acceptable for
> > today's uses (i.e. cipher performance is 2GB/sec+).
>

> AES-NI doesn't help the absurdity of double-encrypting when using scp or
> rsync/ssh over an encrypted VPN, which is where NONE makes sense to use
> for me.

Different layers of protection...

Do you disable all encryption when you're transiting trusted networks
like your VPN? If you don't, why is that ssh session so special?

[Bryan Drewery]

On 11/10/15 3:07 AM, Willem Jan Withagen wrote:
> Which when I found out that upstreaming patches from base will be hard,
> because the whole logging in the ports version is totally different.

No it's not. The HPN patch in the ports version had *extra logging* for
a while but that is not the case now. There is nothing different
compared to upstream OpenSSH now for logging.

--
Regards,
Bryan Drewery

[Bryan Drewery]

On 11/10/15 9:52 AM, John-Mark Gurney wrote:

> My vote is to remove the HPN patches. First, the NONE cipher made more
> sense back when we didn't have AES-NI widely available, and you were
> seriously limited by it's performance. Now we have both aes-gcm and
> chacha-poly which it's performance should be more than acceptable for
> today's uses (i.e. cipher performance is 2GB/sec+).

AES-NI doesn't help the absurdity of double-encrypting when using scp or
rsync/ssh over an encrypted VPN, which is where NONE makes sense to use
for me.

--
Regards,
Bryan Drewery

[Bryan Drewery]

On 11/10/15 1:42 AM, Dag-Erling Smørgrav wrote:

> Some of you may have noticed that OpenSSH in base is lagging far behind
> the upstream code.
>
> The main reason for this is the burden of maintaining the HPN patches.
> They are extensive, very intrusive, and touch parts of the OpenSSH code
> that change significantly in every release. Since they are not
> regularly updated, I have to choose between trying to resolve the
> conflicts myself (hoping I don't break anything) or waiting for them to
> catch up and then figuring out how to apply the new version.
>
> Therefore, I would like to remove the HPN patches from base and refer
> anyone who really needs them to the openssh-portable port, which has
> them as a default option. I would also like to remove the NONE cipher
> patch, which is also available in the port (off by default, just like in
> base).
>
> DES
>

I had this same problem as well, but have since reworked the HPN patch
for ports to be more easily maintained. I've considered offering or
just updating the base SSH, but have not since we have random changes in
the HPN functionality in base that would be lost. We for some reason
decided we were going to maintain our own version and not even upstream
the changes to the HPN authors which has contributed to this situation.

Anyway, reverting the base SSH to stock, and then importing all patches
from the ports default version should result in the same base patches
applied and a working HPN. I've kept the port version up-to-date with
all base changes applied as well (short of HPN customizations we made
that are not worth keeping) A lot of people pressured me to remove HPN
as default from the port (during times that I was too busy to rework the
patch for the latest OpenSSH) but I persisted in keeping it due to it
being enabled in base. If we really remove it from base I may disable
it in the port as well as a default.

I personally find the feature worth keeping. Seeing recent benchmarks
would be a good idea, but the overall patch is quite simple and
non-complex. It's now split up with defines for each feature so they
can be disabled at compile time. See
/usr/ports/security/openssh-portable/files/extra-patch-hpn. There is
HPN_ENABLED and NONE_CIPHER_ENABLED. It's really quite a simple and
small patch after removing all of the bogus changes (which I did
upstream, and did apply to the base HPN as well) and the logging changes
(which were far too intrusive to maintain).

--
Regards,
Bryan Drewery

[Bryan Drewery]

On 11/10/15 4:40 PM, Bryan Drewery wrote:
> Anyway, reverting the base SSH to stock, and then importing all patches
> from the ports default version should result in the same base patches
> applied and a working HPN.

Actually I am missing the client-side VersionAddendum support (ssh.c). I
only have server-side (sshd.c). This is just due to lack of motivation
to import the changes.

[John-Mark Gurney]

Ben Woods wrote this message on Wed, Nov 11, 2015 at 15:40 +0800:

> On Wednesday, 11 November 2015, Bryan Drewery <bdre...@freebsd.org> wrote:
>
> > On 11/10/15 9:52 AM, John-Mark Gurney wrote:
> > > My vote is to remove the HPN patches. First, the NONE cipher made more
> > > sense back when we didn't have AES-NI widely available, and you were
> > > seriously limited by it's performance. Now we have both aes-gcm and
> > > chacha-poly which it's performance should be more than acceptable for
> > > today's uses (i.e. cipher performance is 2GB/sec+).
> >
> > AES-NI doesn't help the absurdity of double-encrypting when using scp or
> > rsync/ssh over an encrypted VPN, which is where NONE makes sense to use
> > for me.
>

> I have to agree that there are cases when the NONE cipher makes sense, and
> it is up to the end user to make sure they know what they are doing.
>
> Personally I have used it at home to backup my old FreeBSD server (which
> does not have AESNI) over a dedicated network connection to a backup server
> using rsync/ssh. Since it was not possible for anyone else to be on that
> local network, and the server was so old it didn't have AESNI and would
> soon be retired, using the NONE cipher sped up the transfer significantly.

If you have a trusted network, why not just use nc?

--
John-Mark Gurney Voice: +1 415 225 5579

"All that I will do, has been done, All that I have, has not."

[Micheas Herman]

On Tue, Nov 10, 2015 at 11:59 PM, John-Mark Gurney <j...@funkthat.com> wrote:
>
> <snip>

>
> If you have a trusted network, why not just use nc?

Defense in depth for starters.

The ipfw how to guide I learned from years ago, started with the
statement that a
firewall should be a shield in front of machines that don't need the shield.

Security is hard, and you will get it wrong (everyone does),
accidentally exposing
an encrypted stream is much less of a mistake than exposing a plaint
text stream.

[Dag-Erling Smørgrav]

Ben Woods <wood...@gmail.com> writes:
> Personally I have used it at home to backup my old FreeBSD server
> (which does not have AESNI) over a dedicated network connection to a
> backup server using rsync/ssh. Since it was not possible for anyone
> else to be on that local network, and the server was so old it didn't
> have AESNI and would soon be retired, using the NONE cipher sped up
> the transfer significantly.

In that scenario, you don't need ssh at all. Just set up rsyncd on the
backup server.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Dag-Erling Smørgrav]

Bryan Drewery <bdre...@FreeBSD.org> writes:
> Actually I am missing the client-side VersionAddendum support (ssh.c). I
> only have server-side (sshd.c). This is just due to lack of motivation
> to import the changes.

Pretty sure I sent Damien the patch a few years ago... There was also a
bug in the server-side code (IIRC, one place where it printed only the
hardcoded version instead of the variable string). I'll try again.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Julian Elischer]

On 11/10/15 5:42 PM, Dag-Erling Smørgrav wrote:
> Some of you may have noticed that OpenSSH in base is lagging far behind
> the upstream code.
>
> The main reason for this is the burden of maintaining the HPN patches.
> They are extensive, very intrusive, and touch parts of the OpenSSH code
> that change significantly in every release. Since they are not
> regularly updated, I have to choose between trying to resolve the
> conflicts myself (hoping I don't break anything) or waiting for them to
> catch up and then figuring out how to apply the new version.
>
> Therefore, I would like to remove the HPN patches from base and refer
> anyone who really needs them to the openssh-portable port, which has
> them as a default option. I would also like to remove the NONE cipher
> patch, which is also available in the port (off by default, just like in
> base).
>
> DES

The inclusion of the HPN patches meant that we could drop a custom
unsupported HPN enabled ssh from our build process.
It makes ssh actually usable.
Without it we need to keep integrating HPN ever time ssh is upgraded.

We were SO HAPPY when it came in by default.

[Julian Elischer]

On 11/10/15 7:16 PM, Dag-Erling Smørgrav wrote:
> Bob Bishop <r...@gid.co.uk> writes:
>> Is removing HPN going to impact the performance of tunnelled X
>> connexions?

yes if your rtt is greater than about 85 mSec
I don't know he details but I noticed a big difference.
I had thought X wouldn't show much difference but in fact it did.
At work we had to add HPN to get anything like acceptable performance
on various tunnels our appliance uses.

> I don't think so. It mostly affects the performance of long
> unidirectional streams (file transfers) whereas the X protocol, as far
> as I know, is a bidirectional exchange of relatively short messages. It
> may make a difference for applications that transfer large textures...
> I don't really know enough about the X protocol to say for certain, but
> I am typing this in Emacs over a non-HPN SSH connection, and I regularly
> tunnel Firefox between the same two machines (RHEL 7 desktop at work and
> FreeBSD 10 desktop at home).
>
> DES

[Dag-Erling Smørgrav]

Julian Elischer <jul...@freebsd.org> writes:
> The inclusion of the HPN patches meant that we could drop a custom
> unsupported HPN enabled ssh from our build process. It makes ssh
> actually usable.

Define "usable". Does it actually make a measurable difference with the
latest OpenSSH? And if HPN is so important to you, is there a reason
why you can't use the port?

DES
--
Dag-Erling Smørgrav - d...@des.no

[Ben Woods]

On Wednesday, 11 November 2015, Bryan Drewery <bdre...@freebsd.org> wrote:

> On 11/10/15 9:52 AM, John-Mark Gurney wrote:
> > My vote is to remove the HPN patches. First, the NONE cipher made more
> > sense back when we didn't have AES-NI widely available, and you were
> > seriously limited by it's performance. Now we have both aes-gcm and
> > chacha-poly which it's performance should be more than acceptable for
> > today's uses (i.e. cipher performance is 2GB/sec+).
>
> AES-NI doesn't help the absurdity of double-encrypting when using scp or
> rsync/ssh over an encrypted VPN, which is where NONE makes sense to use
> for me.
>

I have to agree that there are cases when the NONE cipher makes sense, and
it is up to the end user to make sure they know what they are doing.

Personally I have used it at home to backup my old FreeBSD server (which
does not have AESNI) over a dedicated network connection to a backup server
using rsync/ssh. Since it was not possible for anyone else to be on that
local network, and the server was so old it didn't have AESNI and would
soon be retired, using the NONE cipher sped up the transfer significantly.

If the patch is made easy enough to maintain (as some subsequent posts have
implied), I quote the NONE cipher stays. I would even like to see it
compiled in by default (but disabled in the default configuration file).
That way you wouldn't need a custom compiled base to use it - just edit the
config file.

Regards,
Ben


--

--
From: Benjamin Woods
wood...@gmail.com

[Ben Woods]

On Wednesday, 11 November 2015, John-Mark Gurney <j...@funkthat.com> wrote:

> Ben Woods wrote this message on Wed, Nov 11, 2015 at 15:40 +0800:
> > I have to agree that there are cases when the NONE cipher makes sense,
> and
> > it is up to the end user to make sure they know what they are doing.
> >
> > Personally I have used it at home to backup my old FreeBSD server (which
> > does not have AESNI) over a dedicated network connection to a backup
> server
> > using rsync/ssh. Since it was not possible for anyone else to be on that
> > local network, and the server was so old it didn't have AESNI and would
> > soon be retired, using the NONE cipher sped up the transfer
> significantly.
>
> If you have a trusted network, why not just use nc?
>

Honest answer: ignorance of how I can use netcat together with rsync.

--

--
From: Benjamin Woods
wood...@gmail.com

[Jason Birch]

On Wed, Nov 11, 2015 at 6:59 PM, John-Mark Gurney <j...@funkthat.com> wrote:
> If you have a trusted network, why not just use nc?

Perhaps more generally relevant is that ssh/scp are *waves hands* vaguely
analogous to secure versions of rsh/rlogin/rcp. I'd think that most cases
of "I wanted to send files and invoke some commands on a remote machine,
and due to $CIRCUMSTANCE I don't need or desire encryption" are covered
by the older, also standard tools. Additionally, rsync can use rsh as its
transport, for users who desire more advanced behaviour. ssh just seems
to have more support; Installation will ask you if you'd like to run sshd
(not rshd), ssh is rather ubiquitous as a way of "doing a thing remotely"
(even in Windows soon!), etc. This is a good default to have; the
overhead of security is tiny in nearly all cases.

It would seem then that the extra complexity of maintenance development
in supporting NONE in base doesn't really grant us any additional
functionality in most cases. It's just more 'obvious'.

[Slawa Olhovchenkov]

On Tue, Nov 10, 2015 at 09:52:16AM -0800, John-Mark Gurney wrote:

> Dag-Erling Smrgrav wrote this message on Tue, Nov 10, 2015 at 10:42 +0100:
> > Therefore, I would like to remove the HPN patches from base and refer
> > anyone who really needs them to the openssh-portable port, which has
> > them as a default option. I would also like to remove the NONE cipher
> > patch, which is also available in the port (off by default, just like in
> > base).
>
> My vote is to remove the HPN patches. First, the NONE cipher made more
> sense back when we didn't have AES-NI widely available, and you were
> seriously limited by it's performance. Now we have both aes-gcm and
> chacha-poly which it's performance should be more than acceptable for
> today's uses (i.e. cipher performance is 2GB/sec+).
>
> Second, I did some testing recently due to a thread on -net, and I
> found no significant (not run statistically though) difference in
> performance between in HEAD ssh and OpenSSH 7.1p1. I started a wiki
> page to talk about this:
> https://wiki.freebsd.org/SSHPerf

Hmm, I see in this page max speed 20MB/sec. This is too small.
What is problem? With modern 40G NIC wanted speed about 20Gbit/s.
10Gbit/s at least.

[Slawa Olhovchenkov]

On Tue, Nov 10, 2015 at 11:59:30PM -0800, John-Mark Gurney wrote:

> Ben Woods wrote this message on Wed, Nov 11, 2015 at 15:40 +0800:
> > On Wednesday, 11 November 2015, Bryan Drewery <bdre...@freebsd.org> wrote:
> >
> > > On 11/10/15 9:52 AM, John-Mark Gurney wrote:
> > > > My vote is to remove the HPN patches. First, the NONE cipher made more
> > > > sense back when we didn't have AES-NI widely available, and you were
> > > > seriously limited by it's performance. Now we have both aes-gcm and
> > > > chacha-poly which it's performance should be more than acceptable for
> > > > today's uses (i.e. cipher performance is 2GB/sec+).
> > >
> > > AES-NI doesn't help the absurdity of double-encrypting when using scp or
> > > rsync/ssh over an encrypted VPN, which is where NONE makes sense to use
> > > for me.
> >
> > I have to agree that there are cases when the NONE cipher makes sense, and
> > it is up to the end user to make sure they know what they are doing.
> >
> > Personally I have used it at home to backup my old FreeBSD server (which
> > does not have AESNI) over a dedicated network connection to a backup server
> > using rsync/ssh. Since it was not possible for anyone else to be on that
> > local network, and the server was so old it didn't have AESNI and would
> > soon be retired, using the NONE cipher sped up the transfer significantly.
>
> If you have a trusted network, why not just use nc?

I think you kidding:

- scp need only one command on initiator side and
no additional setup on target. simple, well know.
- nc need additional work on target, need synchronization for file
names with target, also need ssh to target for start, etc... Too
complex.

[Dag-Erling Smørgrav]

Julian Elischer <jul...@freebsd.org> writes:
> Bob Bishop <r...@gid.co.uk> writes:
> > Is removing HPN going to impact the performance of tunnelled X
> > connexions?
> yes if your rtt is greater than about 85 mSec

With an RTT of 85 ms, X is unusable with or without HPN.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Julian Elischer]

On 11/11/15 7:56 PM, Dag-Erling Smørgrav wrote:
> Julian Elischer <jul...@freebsd.org> writes:
>> The inclusion of the HPN patches meant that we could drop a custom
>> unsupported HPN enabled ssh from our build process. It makes ssh
>> actually usable.
> Define "usable". Does it actually make a measurable difference with the
> latest OpenSSH? And if HPN is so important to you, is there a reason
> why you can't use the port?

useable.. able to use more than 5% of the available bandwidth.

Our environment is not freeBSD exactly. many ports won't compile and
we don't have ports in our setup (I didn't do it.. don't blame me)
But we do and can compile FreeBSD sourcers so ssh from src is an easy
recompile or just a binary drop in.
We used to do it by hand from sources ftp'd from OpenBSD and compiled
straight (no ports),
but since it came to have HPN all that went away because the in-tree
one worked for us.
Now we'll have to resurrect all that framework and pain.

have you mentioned this plan to Brooks? Didn't he add it?

>
> DES

[Dag-Erling Smørgrav]

Julian Elischer <jul...@freebsd.org> writes:
> Now we'll have to resurrect all that framework and pain.

I guess pain is fine as long as it's not yours...

> have you mentioned this plan to Brooks? Didn't he add it?

These are public lists, but by all means, mention it to him if he hasn't
noticed this thread.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Dag-Erling Smørgrav]

Daniel Kalchev <dan...@digsys.bg> writes:
> I must have missed the explanation. But why having a NONE cypher
> compiled in, but disabled in the configuration is a bad idea?

It increases the cost of maintaining OpenSSH in base noticeably without
providing real value unless you are one of the few people who need HPN
and lack the CPU power to perform encryption at line speed.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Dag-Erling Smørgrav]

Bryan Drewery <bdre...@FreeBSD.org> writes:
> Another thing that I did with the port was restore the tcpwrapper
> support that upstream removed. Again, if we decide it is not worth
> keeping in base I will remove it as default in the port.

I want to keep tcpwrapper support - it is another reason why I still
haven't upgraded OpenSSH, but to the best of my knowledge, it is far
less intrusive than HPN.

[Bjoern A. Zeeb]

> On 11 Nov 2015, at 16:53 , Bryan Drewery <bdre...@FreeBSD.org> wrote:

>
> On 11/11/2015 8:51 AM, Dag-Erling Smørgrav wrote:
>> Bryan Drewery <bdre...@FreeBSD.org> writes:
>>> Another thing that I did with the port was restore the tcpwrapper
>>> support that upstream removed. Again, if we decide it is not worth
>>> keeping in base I will remove it as default in the port.
>>
>> I want to keep tcpwrapper support - it is another reason why I still
>> haven't upgraded OpenSSH, but to the best of my knowledge, it is far
>> less intrusive than HPN.
>>
>

> Yes, it's very small.
> /usr/ports/security/openssh-portable/files/extra-patch-tcpwrappers

And thanks to both of you for keeping it.
It’s often the best you can get if you have machines which run w/o firewalls.

Just wanted to say “thanks”!

/bz

[Bryan Drewery]

On 11/11/2015 1:23 AM, Dag-Erling Smørgrav wrote:
> Bryan Drewery <bdre...@FreeBSD.org> writes:
>> Actually I am missing the client-side VersionAddendum support (ssh.c). I
>> only have server-side (sshd.c). This is just due to lack of motivation
>> to import the changes.
>
> Pretty sure I sent Damien the patch a few years ago... There was also a
> bug in the server-side code (IIRC, one place where it printed only the
> hardcoded version instead of the variable string). I'll try again.
>

By the way, I may have come off wrong. I'm willing to do the work to
update the base version and put it out for review if you would like.

Another thing that I did with the port was restore the tcpwrapper
support that upstream removed. Again, if we decide it is not worth
keeping in base I will remove it as default in the port.

I honestly don't have a strong opinion on keeping or removing HPN. It is
afterall available in the port and I intend to keep it as an option
there. The question is just what the default is.

I prefer to keep the port close to the base version by default options.
I never liked the idea of having 2 different things in the ecosystem
that behave differently, from OpenSSL to OpenSSH, etc.


--
Regards,
Bryan Drewery

[Bryan Drewery]

On 11/10/2015 3:48 AM, Dag-Erling Smørgrav wrote:
> Willem Jan Withagen <w...@digiware.nl> writes:
>> "Dag-Erling Smørgrav" <d...@des.no> writes:
>>> Willem Jan Withagen <w...@digiware.nl> writes:
>>>> Are they still willing to accept changes to the old version that
>>>> is currently in base?
>>> No, why would they do that?
>> Exactly my question.... I guess I misinterpreted your suggestion on
>> upstreaming patches.
>
> I didn't suggest submitting patches, I suggested submitting a feature
> request. Damien is generally pretty open to suggestions.
>

My own experience here has been positive, both with patches, feature
suggestion, and general discussion. The upstream is more open than
people may think.


--
Regards,
Bryan Drewery

[Bryan Drewery]

On 11/11/2015 8:51 AM, Dag-Erling Smørgrav wrote:

> Bryan Drewery <bdre...@FreeBSD.org> writes:
>> Another thing that I did with the port was restore the tcpwrapper
>> support that upstream removed. Again, if we decide it is not worth
>> keeping in base I will remove it as default in the port.
>
> I want to keep tcpwrapper support - it is another reason why I still
> haven't upgraded OpenSSH, but to the best of my knowledge, it is far
> less intrusive than HPN.
>

Yes, it's very small.
/usr/ports/security/openssh-portable/files/extra-patch-tcpwrappers

--
Regards,
Bryan Drewery

[Bryan Drewery]

On 11/11/2015 1:04 AM, Dag-Erling Smørgrav wrote:
> Ben Woods <wood...@gmail.com> writes:
>> Personally I have used it at home to backup my old FreeBSD server
>> (which does not have AESNI) over a dedicated network connection to a
>> backup server using rsync/ssh. Since it was not possible for anyone
>> else to be on that local network, and the server was so old it didn't
>> have AESNI and would soon be retired, using the NONE cipher sped up
>> the transfer significantly.
>
> In that scenario, you don't need ssh at all. Just set up rsyncd on the
> backup server.
>

Yes, it's more a matter of convenience with key management. I admit that
after some recent changes I've made I did resort to using the base SSH
and rsync:// to achieve my backups over VPN out of not wanting to
customize the the new system further with the port version or rebuilding
base.


--
Regards,
Bryan Drewery

[Daniel Kalchev]

It is my understanding, that using the NONE cypher is not identical to using “the old tools” (rsh/rlogin/rcp).

When ssh uses the NONE cypher, credentials and authorization are still encrypted and verified. Only the actual data payload is not encrypted.

Perhaps similar level of security could be achieved by “the old tools” if they were by default compiled with Kerberos. Although, this still requires building additional infrastructure.

I must have missed the explanation. But why having a NONE cypher compiled in, but disabled in the configuration is a bad idea?

Daniel

> On 11.11.2015 г., at 10:55, Jason Birch <jbi...@jbirch.net> wrote:
>
> On Wed, Nov 11, 2015 at 6:59 PM, John-Mark Gurney <j...@funkthat.com> wrote:
>> If you have a trusted network, why not just use nc?
>
> Perhaps more generally relevant is that ssh/scp are *waves hands* vaguely
> analogous to secure versions of rsh/rlogin/rcp. I'd think that most cases
> of "I wanted to send files and invoke some commands on a remote machine,
> and due to $CIRCUMSTANCE I don't need or desire encryption" are covered
> by the older, also standard tools. Additionally, rsync can use rsh as its
> transport, for users who desire more advanced behaviour. ssh just seems
> to have more support; Installation will ask you if you'd like to run sshd
> (not rshd), ssh is rather ubiquitous as a way of "doing a thing remotely"
> (even in Windows soon!), etc. This is a good default to have; the
> overhead of security is tiny in nearly all cases.
>
> It would seem then that the extra complexity of maintenance development
> in supporting NONE in base doesn't really grant us any additional
> functionality in most cases. It's just more 'obvious'.
> _______________________________________________

> freebsd...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

[Slawa Olhovchenkov]

On Wed, Nov 11, 2015 at 05:51:25PM +0100, Dag-Erling Smørgrav wrote:

> Bryan Drewery <bdre...@FreeBSD.org> writes:
> > Another thing that I did with the port was restore the tcpwrapper
> > support that upstream removed. Again, if we decide it is not worth
> > keeping in base I will remove it as default in the port.
>
> I want to keep tcpwrapper support - it is another reason why I still
> haven't upgraded OpenSSH, but to the best of my knowledge, it is far
> less intrusive than HPN.

Can you explain what is problem?
I am see openssh in base and openssh in ports (more recent version)
with same functionaly patches.
You talk about trouble to upgrade. What is root?
openssh in base have different vendor and/or license?
Or something else?

PS: As I today know, kerberos heimdal is practicaly dead as opensource
project. Have FreeBSD planed switch to MIT Kerberos?
I am know about security/krb5.

[Dag-Erling Smørgrav]

Slawa Olhovchenkov <s...@zxy.spb.ru> writes:
> Can you explain what is problem?

Radical suggestion: read the first email in the thread.

> PS: As I today know, kerberos heimdal is practicaly dead as opensource
> project. Have FreeBSD planed switch to MIT Kerberos? I am know about
> security/krb5.

We switched from MIT to Heimdal at some point in the past for some
reason I don't remember. MIT and Heimdal are *not* interchangeable at
the source or binary level, so switching back is not trivial.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Slawa Olhovchenkov]

On Wed, Nov 11, 2015 at 07:18:31PM +0100, Dag-Erling Smørgrav wrote:

> Slawa Olhovchenkov <s...@zxy.spb.ru> writes:
> > Can you explain what is problem?
>
> Radical suggestion: read the first email in the thread.

I am read and don't understund (you talk about trouble of maintaining
the HPN patches).
I see patched version in ports. This version maintaining.
What is problem? Differnt openssh? Quality of patches?
Different branches?
ports branch is worse (by some reaason) base branch?

> > PS: As I today know, kerberos heimdal is practicaly dead as opensource
> > project. Have FreeBSD planed switch to MIT Kerberos? I am know about
> > security/krb5.
>
> We switched from MIT to Heimdal at some point in the past for some
> reason I don't remember. MIT and Heimdal are *not* interchangeable at

I think because MIT stop development in the past.

> the source or binary level, so switching back is not trivial.

I am know about this.

[John-Mark Gurney]

Daniel Kalchev wrote this message on Wed, Nov 11, 2015 at 17:49 +0200:
> It is my understanding, that using the NONE cypher is not identical to using ???the old tools??? (rsh/rlogin/rcp).

>
> When ssh uses the NONE cypher, credentials and authorization are still encrypted and verified. Only the actual data payload is not encrypted.

Except the point is that you ALREADY trust your network, so you don't
need to encrypt the credentials and authorizations, otherwise, why are
you running unencrypted payloads?

In fact, if you aren't running at least a MAC, or a final verify, and
you're transfering large amounts of data (multiple gigabytes), the data
can and will likely be corrupted...

See:
http://noahdavids.org/self_published/CRC_and_checksum.html

Having not used the NONE cipher, I don't know if the MAC is also
removed or not... Either way, the MAC is still the long poll when
it comes to encryption w/ AES-NI...

--
John-Mark Gurney Voice: +1 415 225 5579

"All that I will do, has been done, All that I have, has not."

[John-Mark Gurney]

Ben Woods wrote this message on Wed, Nov 11, 2015 at 16:27 +0800:
> On Wednesday, 11 November 2015, John-Mark Gurney <j...@funkthat.com> wrote:
>
> > Ben Woods wrote this message on Wed, Nov 11, 2015 at 15:40 +0800:
> > > I have to agree that there are cases when the NONE cipher makes sense,
> > and
> > > it is up to the end user to make sure they know what they are doing.
> > >
> > > Personally I have used it at home to backup my old FreeBSD server (which
> > > does not have AESNI) over a dedicated network connection to a backup
> > server
> > > using rsync/ssh. Since it was not possible for anyone else to be on that
> > > local network, and the server was so old it didn't have AESNI and would
> > > soon be retired, using the NONE cipher sped up the transfer
> > significantly.
> >
> > If you have a trusted network, why not just use nc?
>
> Honest answer: ignorance of how I can use netcat together with rsync.

A quick google of rsync nc, turned up method 2 & 4 from:
https://rsync.samba.org/firewall.html

--
John-Mark Gurney Voice: +1 415 225 5579

"All that I will do, has been done, All that I have, has not."

[Brooks Davis]

On Tue, Nov 10, 2015 at 04:40:42PM -0800, Bryan Drewery wrote:
> On 11/10/15 1:42 AM, Dag-Erling Sm??rgrav wrote:
> > Some of you may have noticed that OpenSSH in base is lagging far behind
> > the upstream code.
> >
> > The main reason for this is the burden of maintaining the HPN patches.
> > They are extensive, very intrusive, and touch parts of the OpenSSH code
> > that change significantly in every release. Since they are not
> > regularly updated, I have to choose between trying to resolve the
> > conflicts myself (hoping I don't break anything) or waiting for them to
> > catch up and then figuring out how to apply the new version.
> >

> > Therefore, I would like to remove the HPN patches from base and refer
> > anyone who really needs them to the openssh-portable port, which has
> > them as a default option. I would also like to remove the NONE cipher
> > patch, which is also available in the port (off by default, just like in
> > base).
>

> I had this same problem as well, but have since reworked the HPN patch
> for ports to be more easily maintained. I've considered offering or
> just updating the base SSH, but have not since we have random changes in
> the HPN functionality in base that would be lost. We for some reason
> decided we were going to maintain our own version and not even upstream
> the changes to the HPN authors which has contributed to this situation.

We had ever intention of upstreaming our cleaned up HPN patches and some
interest from OpenSSH devs to take the window scaling portion of the
patch upstream, but other things intruded and we never found time to
complete that work. I think both the window scaling and NONE cipher
changes are useful, but do not have time to do anything with them. I'm
fine with them being removed from base and replaced or just dropped if
they are in the way of progress.

-- Brooks

[Bryan Drewery]

On 11/11/2015 10:13 AM, Slawa Olhovchenkov wrote:
> On Wed, Nov 11, 2015 at 05:51:25PM +0100, Dag-Erling Smørgrav wrote:
>
>> Bryan Drewery <bdre...@FreeBSD.org> writes:
>>> Another thing that I did with the port was restore the tcpwrapper
>>> support that upstream removed. Again, if we decide it is not worth
>>> keeping in base I will remove it as default in the port.
>>
>> I want to keep tcpwrapper support - it is another reason why I still
>> haven't upgraded OpenSSH, but to the best of my knowledge, it is far
>> less intrusive than HPN.
>
> Can you explain what is problem?
> I am see openssh in base and openssh in ports (more recent version)
> with same functionaly patches.
> You talk about trouble to upgrade. What is root?
> openssh in base have different vendor and/or license?
> Or something else?
>
> PS: As I today know, kerberos heimdal is practicaly dead as opensource
> project. Have FreeBSD planed switch to MIT Kerberos?
> I am know about security/krb5.
>

IMHO the problem comes down to time. Patching an upstream project
increases maintenance cost for upgrading it. Every patch adds up. When
you become busy and don't have time to pay attention to every little
change made in a release, hearing 'removed tcpwrappers support' or
'refactored the code <more> for libssh usage' makes it sound like 1 more
thing you must deal with to upgrade that code base and more effort to
validate that your patches are right. We obviously don't want to just
drop in the latest code and throw it out there as broken. SSH is quite
critical and we want to ensure our changes are still right, and that
doing something like adding tcpwrappers back in won't introduce some
security bug that upstream was coy about.

--
Regards,
Bryan Drewery

[Bryan Drewery]

On 11/10/2015 1:42 AM, Dag-Erling Smørgrav wrote:
> I would also like to remove the NONE cipher
> patch, which is also available in the port (off by default, just like in
> base).

Fun fact, it's been broken in the port for several months with no
complaints. It was just reported and fixed upstream in the last day and
I wrote in a similar fix in the port. That speaks a lot about its usage
in the port currently.

--
Regards,
Bryan Drewery

[Robert Simmons]

I don't think there is such a thing as a trusted network. That is a unicorn
these days.

If you are using ssh to connect to the VPN server itself over the VPN
connection, I can see why that would be useless double encryption. However,
if you are connecting to a server on the network on the other side of the
VPN, I would still use ssh. No networks should be considered trusted.

Here is a great article about Beyond Corp, a Google project based on the
idea that trusted networks do not exist in reality, and that systems need
to be built with this in mind.
https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43231.pdf


On Tue, Nov 10, 2015 at 8:41 PM, John-Mark Gurney <j...@funkthat.com> wrote:

> Bryan Drewery wrote this message on Tue, Nov 10, 2015 at 16:32 -0800:
> > On 11/10/15 9:52 AM, John-Mark Gurney wrote:
> > > My vote is to remove the HPN patches. First, the NONE cipher made more
> > > sense back when we didn't have AES-NI widely available, and you were
> > > seriously limited by it's performance. Now we have both aes-gcm and
> > > chacha-poly which it's performance should be more than acceptable for
> > > today's uses (i.e. cipher performance is 2GB/sec+).
> >
> > AES-NI doesn't help the absurdity of double-encrypting when using scp or
> > rsync/ssh over an encrypted VPN, which is where NONE makes sense to use
> > for me.
>

> Different layers of protection...
>
> Do you disable all encryption when you're transiting trusted networks
> like your VPN? If you don't, why is that ssh session so special?

[Benjamin Kaduk]

On Wed, 11 Nov 2015, Daniel Kalchev wrote:

>
> Perhaps similar level of security could be achieved by “the old tools”
> if they were by default compiled with Kerberos. Although, this still
> requires building additional infrastructure.

The kerberized versions of the old tools are basically unsupported
upstream at this point. Telnet is actively insecure, being limited to
single-DES; rlogin may be somewhat better but it's still not looking very
good. ssh is better because it speaks GSS-API instead of raw kerberos,
and can thus keeps up with newer crypto automatically.

When I was working at MIT, I considered making a final release of the
krb5-appl distribution, so as to include in the release announcement that
they were not going to be supported further, but could not even bring
myself to do that. They are not in Debian anymore, and I expect them to
dwindle from other distributions, too.

Let the "old tools" grow old and retire.

-Ben

[Leif Pedersen]

On Wed, Nov 11, 2015 at 4:29 PM, Robert Simmons <rsim...@gmail.com> wrote:

> I don't think there is such a thing as a trusted network. That is a unicorn
> these days.
>

> No networks should be considered trusted.
>

oh baloney. That's just a clever way to say you want to stop thinking about
trust.

If I've connected two machines directly, that network is more trustworthy
than any encryption. This is not rare, but typical for system recovery,
which is where nc and ssh with the none cipher are highly useful.

It's also not a bridge too far to claim a network is trusted when it has
1000 computers on a special-purpose processing network with access only
allowed by the admins that built it, and perhaps an API. In those networks,
the nodes work together like storage and CPUs work together in a single
computer. The only difference is that SATA disks and x86 CPUs are replaced
by general-purpose computers running Cassandra and Nginx, connected by
ethernet, so that you can connect thousands together instead of dozens. Do
you always insist on encryption on your SATA cables and memory buses?

That sort of special-purpose network is not rare either; rather it's
typical for internet services where the load is beyond what a single
machine can handle, or clusters that run models that are too large for a
single machine.

Trustworthy networks do exist. They just aren't the same networks as 20
years ago.

--

As implied by email protocols, the information in this message is
not confidential. Any middle-man or recipient may inspect, modify,
copy, forward, reply to, delete, or filter email for any purpose unless
said parties are otherwise obligated. As the sender, I acknowledge that
I have a lower expectation of the control and privacy of this message
than I would a post-card. Further, nothing in this message is
legally binding without cryptographic evidence of its integrity.

http://bilbo.hobbiton.org/wiki/Eat_My_Sig

[Slawa Olhovchenkov]

Some for as ports version?
Or ports version different?
Or port mantainer have more time (this is not to blame for DES)?
I am just don't know what is different between port ssh and base ssh.
We need ssh 6.x in base, not 7.x as in port (why?) and this is need
independed work on pathes?
I am missing somehow commonplace for others.

[Slawa Olhovchenkov]

On Wed, Nov 11, 2015 at 03:58:35PM -0800, Bryan Drewery wrote:

> > Some for as ports version?
> > Or ports version different?
> > Or port mantainer have more time (this is not to blame for DES)?
> > I am just don't know what is different between port ssh and base ssh.
> > We need ssh 6.x in base, not 7.x as in port (why?) and this is need
> > independed work on pathes?
> > I am missing somehow commonplace for others.
> >
>

> I am the ports maintainer. That was my opinion on why OpenSSH falls
> behind. There is no real difference between the base and port version
> except that the port version has some more optional patches, and is
> easier to push updates for through ports and packages, rather than an
> Errata through freebsd-update or a full release to get to the latest
> OpenSSH version.

This impact only to deploy, not to patch, right?
Or bugs found around NPH/NONE patches?

> There have been many times where the base version was more up-to-date
> than the port as well due to the lack of a maintainer or the previously
> mentioned patch blockers.

[Slawa Olhovchenkov]

I am try using NPH/NONE with base ssh and confused: don't see
performance rise, too complex to enable and too complex for use.

[Bryan Drewery]

I am the ports maintainer. That was my opinion on why OpenSSH falls
behind. There is no real difference between the base and port version
except that the port version has some more optional patches, and is
easier to push updates for through ports and packages, rather than an
Errata through freebsd-update or a full release to get to the latest
OpenSSH version.

There have been many times where the base version was more up-to-date
than the port as well due to the lack of a maintainer or the previously
mentioned patch blockers.

--
Regards,
Bryan Drewery

[Bryan Drewery]

On 11/11/15 4:05 PM, Slawa Olhovchenkov wrote:
> On Wed, Nov 11, 2015 at 03:58:35PM -0800, Bryan Drewery wrote:
>
>>> Some for as ports version?
>>> Or ports version different?
>>> Or port mantainer have more time (this is not to blame for DES)?
>>> I am just don't know what is different between port ssh and base ssh.
>>> We need ssh 6.x in base, not 7.x as in port (why?) and this is need
>>> independed work on pathes?
>>> I am missing somehow commonplace for others.
>>>
>>
>> I am the ports maintainer. That was my opinion on why OpenSSH falls
>> behind. There is no real difference between the base and port version
>> except that the port version has some more optional patches, and is
>> easier to push updates for through ports and packages, rather than an
>> Errata through freebsd-update or a full release to get to the latest
>> OpenSSH version.
>
> This impact only to deploy, not to patch, right?

It's harder to maintain the port version due to how the patches are
applied and generated. That's only my problem though.

> Or bugs found around NPH/NONE patches?
>
>> There have been many times where the base version was more up-to-date
>> than the port as well due to the lack of a maintainer or the previously
>> mentioned patch blockers.

--
Regards,
Bryan Drewery

[Robert Simmons]

Oh just the opposite of what you're claiming. Did you even read the article
about the Beyond Corp project? It is 100% about thinking very hard about
trust and making sure that the trust model used doesn't depend on the
concept of internal/external network.

Also, the type of thinking where two or more machines are connected
directly or are on their own separate network is what lands you in a
situation like BACnet. Now you have a pentester with a vampire tap in the
basement lobby sniffing your unencrypted traffic on your "trusted" BACnet.

[Dag-Erling Smørgrav]

Bryan Drewery <bdre...@FreeBSD.org> writes:
> It's harder to maintain the port version due to how the patches are
> applied and generated.

I have the diametrically opposite experience. The workflow for ports is
significantly simpler than for base. Perhaps I should set up a paralell
workflow for OpenSSH and apply the output of that workflow to the source
tree instead of working entirely within the source tree.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Dewayne Geraghty]

Slawa,
Heimdal is (and has been for some time) undergoing constant development.
For reasons unknown, they do not perform releases. I am aware of updates
from heimdal that are being applied to the samba project (in fact some of
the samba developers are also feeding into heimdal). The latest discussion
was that the heimdal project are going to release a 1.7 "sometime",
skipping 1.6 completely.

Des - good to make your intentions public. I've enjoyed your youtube
presentations and recognise that your time will be better spent. ( better
authentication perhaps ;) )

Bryan - is doing a good job of looking after the openssh port. And if
folks really need those additional features, then that is the place to
enhance the "standard" offering; which can be upgraded in a pretty
straightforward manner.

Thought-provoking use of inetd perhaps its time to revisit as (an
additional) DOS measure(?)

Regards, Dewayne.
PS My apologies for the repetition Slawa, I meant to reply all earlier.
I'm recently becoming familiar with the gmail interface.

[Benjamin Kaduk]

On Thu, 12 Nov 2015, Dewayne Geraghty wrote:

> Heimdal is (and has been for some time) undergoing constant development.
> For reasons unknown, they do not perform releases. I am aware of updates
> from heimdal that are being applied to the samba project (in fact some of
> the samba developers are also feeding into heimdal). The latest discussion
> was that the heimdal project are going to release a 1.7 "sometime",
> skipping 1.6 completely.

Things seem to have slowed down a lot since the lead Heimdal developer got
hired for Apple. They have Apple-internal changes that don't necessarily
make their way back to the public project right away, and he is quite
busy. There is no one who is employed to be a Heimdal release manager,
and the main developers all have other projects -- putting out a release
takes a fair bit of energy. MIT employs developers whose job descriptions
include being the krb5 release manager, so there is financial support for
putting out regular releases.

Heimdal has changed plans to a 1.7 release because certain Linux
distributions packaged a snapshot of the 1.6 tree (to support Samba, as I
understand it), but then Heimdal development continued so that what would
be in the next release would not really reflect what was already deployed
using the 1.6 label. As I understand it, there are still a couple
bugfixes/features that are considered to be blockers for the 1.7 release
that have not been implemented yet, and since the developers in question
are being paid to work on other things, there is no real timeline for the
release.


-Ben Kaduk

[Julian Elischer]

it would be nice if the outcome of this thread was that HPN patches
(or something equivalent) were available by default in OpenSSH.
WE also have our own patch we add to give a NODELAY option.
It made a huge difference with tunnels where lots of small RPC packets
were being sent.
I'll look at getting it into upstream.


>
> -- Brooks

[Julian Elischer]

we use it all the time, we just don't update all that often.

[Dag-Erling Smørgrav]

Benjamin Kaduk <ka...@MIT.EDU> writes:
> Things seem to have slowed down a lot since the lead Heimdal developer

> got hired for Apple. [...] MIT employs developers whose job
> descriptions include being the krb5 release manager [...] Heimdal has
> changed plans to a 1.7 release [...] and since the developers in

> question are being paid to work on other things, there is no real
> timeline for the release.

Given this state of affairs, it might not be unreasonable to consider
switching back for 11. There should be enough time, provided our
Kerberos maintainers have some spare cycles.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Brooks Davis]

On Tue, Nov 24, 2015 at 09:29:44PM +0100, Aaron Zauner wrote:
> Hi,
>
> Please forgive my ignorance but what's the reason FreeBSD ships
> OpenSSH patched with HPN by default? Besides my passion for
> security, I've been working in the HPC sector for a while and
> benchmarked the patch for a customer about 1.5 years ago. The
> CTR-multi threading patch is actually *slower* than upstream OpenSSH
> with AES in CTR mode. GCM being, of course, the fastest mode on
> AESNI plattforms.

We never imported the AES bits as they were broken and AESNI was
available.

> The NULL mode is a security concern as some have noted, I can only
> imagine that the window-scaling patch is of such importance?

Both NULL and window-scaling were merged because both are useful in some
environments.

-- Brooks

[Julian Elischer]

yeah but Null was just unmerged.
window scaling is also on the block I think
>
> -- Brooks

[Benjamin Kaduk]

(was Re: OpenSSH HPN)

[See
https://lists.freebsd.org/pipermail/freebsd-security/2015-November/008747.html
for the bits that Dag-Erling skipped]

On Fri, 13 Nov 2015, Dag-Erling Smørgrav wrote:

> Benjamin Kaduk <ka...@MIT.EDU> writes:
> > Things seem to have slowed down a lot since the lead Heimdal developer
> > got hired for Apple. [...] MIT employs developers whose job
> > descriptions include being the krb5 release manager [...] Heimdal has
> > changed plans to a 1.7 release [...] and since the developers in
> > question are being paid to work on other things, there is no real
> > timeline for the release.
>
> Given this state of affairs, it might not be unreasonable to consider
> switching back for 11. There should be enough time, provided our
> Kerberos maintainers have some spare cycles.

Well, it's definitely too late for 11, now.

But, Debian is preparing to remove their heimdal package entirely,
imminently: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837728

I also can't find an archive of heimdal...@sics.se that still works
(now that gmane is gone), so I'll quote the relevant message from there,
below.

Maybe we should consider dropping heimdal for 12.

-Ben

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Date: Wed, 14 Sep 2016 14:58:27 -0400
From: Andrew Bartlett <abar...@samba.org>
To: heimdal...@sics.se
Subject: Heimdal to be removed from Debian shortly

FYI:
I'm sorry to say that per:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834654
and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837728

Heimdal will shortly be removed from Debian.
It is the view of those
of us involved that inclusion of sensitive security software in the
next stable release of Debian needs the normal pattern of maintained
upstream releases, not just a git tree to take snapshots from.

It is also being eased out of Samba, we will make further decisions
once we get a build against MIT krb5 working.

Sorry,

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.orgSamba Developer,
Catalyst IT http://catalyst.net.nz/services/samba

[Dewayne Geraghty]

Begs the question-what impact to FreeBSD distribution or use will US export
control laws have, if FreeBSD migrated to MIT Kerberos?

--
*Disclaimer:*



*As implied by email protocols, the information in this message is not
confidential. Any intermediary or recipient may inspect, modify (add),

copy, forward, reply to, delete, or filter email for any purpose unless

said parties are otherwise obligated. Nothing in this message may be
legally binding without cryptographic evidence of its integrity and/or
confidentiality.*

[Benjamin Kaduk]

On Wed, 14 Sep 2016, Garrett Wollman wrote:

> <<On Wed, 14 Sep 2016 15:21:46 -0400 (EDT), Benjamin Kaduk <ka...@MIT.EDU> said:
>
> > Well, it's definitely too late for 11, now.
>
> > But, Debian is preparing to remove their heimdal package entirely,
> > imminently: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837728
>

[...]
>
> Since 11.0 hasn't been released yet, is it within the realm of
> possibility to officially deprecate Heimdal-in-base before it ships?
> At this stage all that would involve is putting an announcement in the
> release notes.

If you're going to propose that, asking re@ seems like the right things to
do. Adding them to the recipient list...

-Ben

[Garrett Wollman]

<<On Wed, 14 Sep 2016 15:21:46 -0400 (EDT), Benjamin Kaduk <ka...@MIT.EDU> said:

> Well, it's definitely too late for 11, now.

> But, Debian is preparing to remove their heimdal package entirely,
> imminently: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837728

The primary issue, so far as I can see, is that Heimdal and MIT were
only compatible in the parts of the API that were formally
standardized. For those of us who need MIT (to have a working kadmin,
for example), that has pretty much always boiled down to completely
disabling Heimdal in base (and anything that depends on it, like
OpenSSH, pam_krb5, and GSSAPI-authenticated NFS), and installing
replacement bits from ports/packages.

If we're going to remove Heimdal from base, we should completely
deorbit (or disable, as appropriate) all of the things that depend on
it, and make sure that there are ports that provide replacement
functionality. (AFAIK the only thing missing is gssd, the user-mode
side of the authenticated NFS support.) My bet would be that very few
FreeBSD users actually take advantage of this support, and unless
they're running in an all-FreeBSD or all-Heimdal shop probably have to
install MIT Kerberos anyway.

Since we're expecting to have packaged base complete for 12.0, having
to install a few extra packages (and replace some base packages with
ports packages) should not be an imposition, for those people who want
Kerberos support, and for many of us it would make fresh installs less
of a hassle.

Since 11.0 hasn't been released yet, is it within the realm of
possibility to officially deprecate Heimdal-in-base before it ships?
At this stage all that would involve is putting an announcement in the
release notes.

-GAWollman
(writing as the administrator of the CSAIL.MIT.EDU realm, but still
not speaking for MIT)

[Mathieu Arnold]

Le 14/09/2016 à 23:36, Dewayne Geraghty a écrit :
> Begs the question-what impact to FreeBSD distribution or use will US export
> control laws have, if FreeBSD migrated to MIT Kerberos?

I don't think it would have any impact, these days, the restrictions,
from what I understand, only apply to military grade hardware or
military only encryption ciphers.


--
Mathieu Arnold

[Slawa Olhovchenkov]

On Wed, Sep 14, 2016 at 10:07:15PM -0400, Garrett Wollman wrote:

> <<On Wed, 14 Sep 2016 15:21:46 -0400 (EDT), Benjamin Kaduk <ka...@MIT.EDU> said:
>
> > Well, it's definitely too late for 11, now.
>
> > But, Debian is preparing to remove their heimdal package entirely,
> > imminently: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837728
>
> The primary issue, so far as I can see, is that Heimdal and MIT were
> only compatible in the parts of the API that were formally
> standardized. For those of us who need MIT (to have a working kadmin,
> for example), that has pretty much always boiled down to completely
> disabling Heimdal in base (and anything that depends on it, like
> OpenSSH, pam_krb5, and GSSAPI-authenticated NFS), and installing
> replacement bits from ports/packages.
>
> If we're going to remove Heimdal from base, we should completely
> deorbit (or disable, as appropriate) all of the things that depend on
> it, and make sure that there are ports that provide replacement
> functionality. (AFAIK the only thing missing is gssd, the user-mode
> side of the authenticated NFS support.) My bet would be that very few
> FreeBSD users actually take advantage of this support, and unless
> they're running in an all-FreeBSD or all-Heimdal shop probably have to
> install MIT Kerberos anyway.

I am use gssd. For $HOME over NFS.