openssh bugs - Feb 2008 - [Bug 1440] New: OpenSSL engine support should be enabled by default

https://bugzilla.mindrot.org/show_bug.cgi?id=1440

           Summary: OpenSSL engine support should be enabled by default
    Classification: Unclassified
           Product: Portable OpenSSH
           Version: 4.7p1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P3
         Component: Build system
        AssignedTo: bitbucket at mindrot.org
        ReportedBy: openssh-bugs at lister.dnsalias.net


OpenSSH provides a --with-ssl-engine configure option to enable
OpenSSL's hardware crypto support. The default is not to enable it. I
don't see any reason not to enable it; it has no effect if no hardware
crypto devices are available. I believe the default should be to enable
it, and I even don't think it would be any loss to remove the configure
option altogether (i.e. to always enable it).

Ian

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1440





--- Comment #1 from Ian Lister <openssh-bugs at lister.dnsalias.net> 
2008-02-11 16:59:49 ---
Created an attachment (id=1454)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1454)
Patch to enable engine support by default

This patch changes the behaviour of the configure script to enable
OpenSSL support by default, and to disable it only if explicitly
requested or if it is unavailable.

Ian

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1440


Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au




--- Comment #2 from Darren Tucker <dtucker at zip.com.au>  2008-06-15
04:01:52 ---
I think the danger here is if you end up using contexts on your crypto
hardware for (low-bandwidth) ssh sessions, rather that whatever you
bought the hardware for (eg handling SSL).

I would be interested in hearing from folks who have such hardware,
though.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1440


Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX




--- Comment #3 from Darren Tucker <dtucker at zip.com.au>  2009-07-31
10:46:55 ---
We have decided not to do this at this time due to the potential impact
to some classes of hardware engines.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1440





--- Comment #4 from Ian Lister <openssh-bugs at lister.dnsalias.net> 
2009-07-31 12:16:22 ---
The motivating case for me is on machines with VIA CPUs with Padlock
support (hardware implementations of a range of crypto functions
including AES, SHA-1, SHA-256, random number generation and Montgomery
multiplication).  These are implemented on the CPU core and use the
CPU's ordinary registers and memory for context.  There's no advantage
in doing things the slow way by using the CPU's regular instructions
rather than these special-purpose ones.

Given what you've pointed out about other classes of hardware engine, I
guess I should file a new bug requesting some means of distinguishing
classes of hardware engine?

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1440





--- Comment #5 from Darren Tucker <dtucker at zip.com.au>  2009-07-31
15:21:10 ---
(In reply to comment #4)
> Given what you've pointed out about other classes of hardware engine, I
> guess I should file a new bug requesting some means of distinguishing
> classes of hardware engine?
IMO the most sensible way to handle this is for libcrypto to
automatically use the processor feature if appropriate (OpenBSD does
this).  Some Linux vendors ship different openssl packages for
different processors (i386 vs i686, the latter making use of
instructions not available on previous generations of processors). 
Anyway, I think it doesn't make sense to have every crypto-using
application have to deal with this.

Doing a bit of reading
(http://marc.info/?l=openssl-dev&m=108903127031777&w=2) it looks like
another option is to use openssl.cnf via its [engine_section] (see
http://www.daemon-systems.org/man/openssl.cnf.5.html)

Based on http://www.openssl.org/docs/crypto/OPENSSL_config.html, it
looks like all we'd have to do is add a call of OPENSSL_config(NULL) to
ssh, which I think would be reasonable (assuming it does what I think
it does).

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1440

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #6 from Damien Miller <djm at mindrot.org> 2009-10-06 15:03:16
EST ---
Mass move of RESOLVED bugs to CLOSED now that 5.3 is out.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.