Re: [openssl-users] Selection of DHE ciphers based on modulus size of DH
Hello, Thank you all for your responses. I forgot to mention that we are on OpenSSL 1.1.0 and TLS 1.2. I have some more queries though. >>Current OpenSSL isn't willing to connect to a server using a DH key size below 1024 bits. Yes, i have verified this. However, not sure, how my OpenSSL-based client can do this, as our requirement is that we must not use DH key size below 2048 bits. >> I'm pretty sure that clients can and do refuse to talk to servers with small DH parameters. Could you please provide some more clues how a client can do so ? >> However, in TLS 1.3, the FFDHE groups are pre-defined, and the server >>does not get to choose ad-hoc (p, g) pairs Yep; i saw them. Here, client plays a role to offer the supported DHE first and then, the server can use that - just like elliptic curve negotiation. But again, one catch is that custom DH groups are no more allowed, for which i didn't find a good reasoning. Regards, Sanjaya On Thu, Jun 7, 2018 at 8:52 AM, Jordan Brown wrote: > On 6/6/2018 12:11 PM, Sanjaya Joshi wrote: > > I understood that when DHE ciphers are tried to be used between two > entities, it's only the server that plays a role about selection of the DH > parameters. This is not negotiable with the client. For e.g., the server > can freely use a very low not-recommended DH group with 512 bit key length > and the client cannot deny it. > > > I'm pretty sure that clients can and do refuse to talk to servers with > small DH parameters. > > Current OpenSSL isn't willing to connect to a server using a DH key size > below 1024 bits. > > https://www.openssl.org/blog/blog/2015/05/20/logjam-freak- > upcoming-changes/ > > To protect OpenSSL-based clients, we’re increasing the minimum accepted DH > key size to 768 bits immediately in the next release, and to 1024 bits soon > after. > > > -- > Jordan Brown, Oracle Solaris > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] 2 openssl installed?
t's a server installed many many years ago and there are
applications which are no used.
Server is too late and I have new server
(latest Centos 6) for migrating where I installed latest version.
I'd
like to take to new server all certificate database (certificated
included) which I created.
Openssl is only tool to create test
certificates.
I don't know if there are apps which are using the e
configs, but I think no.
thanks
Il 05.06.2018 09:37 FooCrypt ha
scritto:
> Yeah, typo, forgot -name
>
> looks like its using all the
usr & lib libraries and nothing from /usr/local/….. where you 97e files
are.
>
> I don't know what you are using that system for, but is there
a reason why you are not running 1.0.2g or g+ ?
>
> Are there other
apps on the host which are using the e configs ?
>
>> On 5 Jun 2018, at
4:53 PM, Sampei wrote: Perhaps it's missing -'name openssl' in the 3
commands. However I run: 1) find / -type f -name openssl -exec ldd {} ;
libssl.so.4 => /lib/libssl.so.4 (0x0098f000) libgssapi_krb5.so.2 =>
/usr/lib/libgssapi_krb5.so.2 (0x00718000) libkrb5.so.3 =>
/usr/lib/libkrb5.so.3 (0x0083) libcom_err.so.2 =>
/lib/libcom_err.so.2 (0x006ee000) libk5crypto.so.3 =>
/usr/lib/libk5crypto.so.3 (0x0080c000) libresolv.so.2 =>
/lib/libresolv.so.2 (0x006d9000) libcrypto.so.4 => /lib/libcrypto.so.4
(0x0089b000) libdl.so.2 => /lib/libdl.so.2 (0x0067c000) libz.so.1 =>
/usr/lib/libz.so.1 (0x00682000) libc.so.6 => /lib/libc.so.6 (0x0052a000)
/lib/ld-linux.so.2 (0x0050c000) 2) find / -type f -name openssl -exec
objdump -x {} ; /usr/bin/openssl: file format elf32-i386
/usr/bin/openssl architecture: i386, flags 0x0112: EXEC_P, HAS_SYMS,
D_PAGED start address 0x08054490 Program Header: PHDR off 0x0034
vaddr 0x08048034 paddr 0x08048034 align 2**2 filesz 0x00e0 memsz
0x00e0 flags r-x INTERP off 0x0114 vaddr 0x08048114 paddr
0x08048114 align 2**0 filesz 0x0013 memsz 0x0013 flags r-- LOAD
off 0x vaddr 0x08048000 paddr 0x08048000 align 2**12 filesz
0x0004f678 memsz 0x0004f678 flags r-x LOAD off 0x0005 vaddr
0x08098000 paddr 0x08098000 align 2**12 filesz 0x7174 memsz
0x7174 flags rw- DYNAMIC off 0x00052420 vaddr 0x0809a420 paddr
0x0809a420 align 2**2 filesz 0x0110 memsz 0x0110 flags rw- NOTE
off 0x0128 vaddr 0x08048128 paddr 0x08048128 align 2**2 filesz
0x0020 memsz 0x0020 flags r-- STACK off 0x vaddr
0x paddr 0x align 2**2 filesz 0x memsz
0x flags rw- Dynamic Section: NEEDED libssl.so.4 NEEDED
libgssapi_krb5.so.2 NEEDED libkrb5.so.3 NEEDED libcom_err.so.2 NEEDED
libk5crypto.so.3 NEEDED libresolv.so.2 NEEDED libcrypto.so.4 NEEDED
libdl.so.2 NEEDED libz.so.1 NEEDED libc.so.6 INIT 0x80516f8 FINI
0x8086ca8 HASH 0x8048148 STRTAB 0x809becc SYMTAB 0x804958c STRSZ 0x3295
SYMENT 0x10 DEBUG 0x0 PLTGOT 0x809a544 PLTRELSZ 0x16b8 PLTREL 0x11
JMPREL 0x8050040 REL 0x804fed0 RELSZ 0x170 RELENT 0x8 VERNEED 0x804fe90
VERNEEDNUM 0x1 VERSYM 0x804f882 0x6ef9 0x804c5ec 0x6df7 0xdc
0x6ef8 0x804c6c8 0x6df6 0x108 Version References: required from
libc.so.6: 0x0d696913 0x00 04 GLIBC_2.3 0x0d696911 0x00 03 GLIBC_2.1
0x0d696910 0x00 02 GLIBC_2.0 Sections: Idx Name Size VMA LMA File off
Algn 0 .interp 0013 08048114 08048114 0114 2**0 CONTENTS, ALLOC,
LOAD, READONLY, DATA 1 .note.ABI-tag 0020 08048128 08048128 0128
2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .hash 1444 08048148
08048148 0148 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .dynsym
3060 0804958c 0804958c 158c 2**2 CONTENTS, ALLOC, LOAD,
READONLY, DATA 4 .gnu.liblist 00dc 0804c5ec 0804c5ec 45ec 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .gnu.conflict 0108 0804c6c8
0804c6c8 46c8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6
.gnu.version 060c 0804f882 0804f882 7882 2**1 CONTENTS, ALLOC,
LOAD, READONLY, DATA 7 .gnu.version_r 0040 0804fe90 0804fe90
7e90 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .rel.dyn 0170
0804fed0 0804fed0 7ed0 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 9
.rel.plt 16b8 08050040 08050040 8040 2**2 CONTENTS, ALLOC, LOAD,
READONLY, DATA 10 .init 0017 080516f8 080516f8 96f8 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE 11 .plt 2d80 08051710 08051710
9710 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 12 .text 00032818
08054490 08054490 c490 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 13
.fini 001b 08086ca8 08086ca8 0003eca8 2**2 CONTENTS, ALLOC, LOAD,
READONLY, CODE 14 .rodata 00010991 08086ce0 08086ce0 0003ece0 2**5
CONTENTS, ALLOC, LOAD, READONLY, DATA 15 .eh_frame 0004 08097674
08097674 0004f674 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 16 .data
2420 08098000 08098000 0005 2**5 CONTENTS, ALLOC, LOAD, DATA 17
.dynamic 0110 0809a420 0809a420 00052420 2**2 CONTENTS, ALLOC, LOAD,
DATA 18 .ctors 0008 0809a530 0809a530 00052530 2**2 CONTENTS, ALLOC,
LOAD, DATA 19 .dtors 0008 0809a538 0809a538 00052538 2**2 CONTENTS,
ALLOC, LO
Re: [openssl-users] Selection of DHE ciphers based on modulus size of DH
On 6/6/2018 12:11 PM, Sanjaya Joshi wrote: > I understood that when DHE ciphers are tried to be used between two > entities, it's only the server that plays a role about selection of > the DH parameters. This is not negotiable with the client. For e.g., > the server can freely use a very low not-recommended DH group with 512 > bit key length and the client cannot deny it. I'm pretty sure that clients can and do refuse to talk to servers with small DH parameters. Current OpenSSL isn't willing to connect to a server using a DH key size below 1024 bits. https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ To protect OpenSSL-based clients, we’re increasing the minimum accepted DH key size to 768 bits immediately in the next release, and to 1024 bits soon after. -- Jordan Brown, Oracle Solaris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Selection of DHE ciphers based on modulus size of DH
> On Jun 6, 2018, at 7:15 PM, Salz, Rich via openssl-users > wrote: > > Without commenting on whether or not your understanding is correct (the > client gets the params and can see how big the key is, no?), I will point out > that the way DHE works is defined by the IETF RFC’s, and they have not > changed. However, in TLS 1.3, the FFDHE groups are pre-defined, and the server does not get to choose ad-hoc (p, g) pairs. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Selection of DHE ciphers based on modulus size of DH
Without commenting on whether or not your understanding is correct (the client gets the params and can see how big the key is, no?), I will point out that the way DHE works is defined by the IETF RFC’s, and they have not changed. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] PRNG is not seeded
On 06/06/2018 09:12 PM, openssl-users-requ...@openssl.org digestributed: > Date: Wed, 6 Jun 2018 16:12:59 + > From: Michael Wojcik > >> Hence my solution of using a hardware TRNG shared over the >> network with devices that lack the ability to have one added >> locally. > > Yes, I think that's a good approach. It reduces the attack surface, > since the client device can connect to the entropy-gathering device > with considerable assurance (it can be configured with a pinned CA > or PSK, etc), and at startup can use some entropy saved from the > previous run. An attacker in a privileged position could try active > attacks like a DoS against the connection to the entropy server, but > a (more dangerous) passive attack looks very difficult. Speaking of attack scenarios, I refreshed my info after this discussion and wondered how likely it is that someone (in a Linux world) would want to attack the entropy *sources* directly. A manipulated source's effect on applications (that read from /dev/random) would be somewhat limited due to the kernel folding in other sources as well (memento Linus' statement about RDRAND), and due to the fact that *many* consumers read from it (you cannot predict who gets which part of your manipulated entropy). For comparison, imagine someone attacking the kernel and manipulating the /dev/random driver so that it feeds predictable sequences to the targets (processes running executables "httpd", "gpg", etc.) but real pool data to all other consumers. Presto, a subverted system that still gets a clean bill of health from rngtest, ent, dieharder, or whatever other analyzer you care to try ... ... by which I mean to ask, since I read a quest for suitable entropy-distribution protocols between the lines here, maybe there is something to be said in favor of signed-at-source chunks of entropy being forwarded *through* the kernel unchanged, and leaving the trust-based selection of sources and final folding to the individual applications? > And it's practical for real-world data centers; implementation and > equipment costs are low. [has been trying to acquire a better *NTP* source than public unsigned servers in certain data centers for 8+ years] :-C Regards, -- Jochen Bern Systemingenieur www.binect.de www.facebook.de/binect smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Selection of DHE ciphers based on modulus size of DH
Hello, I understood that when DHE ciphers are tried to be used between two entities, it's only the server that plays a role about selection of the DH parameters. This is not negotiable with the client. For e.g., the server can freely use a very low not-recommended DH group with 512 bit key length and the client cannot deny it. Is this understanding still correct or this has been changed recently ? Regards, Sanjaya -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] PRNG is not seeded
> From: openssl-users on behalf of Jakob > Bohm > Sent: Tuesday, June 5, 2018 02:46 > Hence my solution of using a hardware TRNG shared over the > network with devices that lack the ability to have one added > locally. Yes, I think that's a good approach. It reduces the attack surface, since the client device can connect to the entropy-gathering device with considerable assurance (it can be configured with a pinned CA or PSK, etc), and at startup can use some entropy saved from the previous run. An attacker in a privileged position could try active attacks like a DoS against the connection to the entropy server, but a (more dangerous) passive attack looks very difficult. And it's practical for real-world data centers; implementation and equipment costs are low. It should even be possible to do this with one of those SOHO WIFi routers that have USB ports and media-sharing features, for use by smartphone apps and the like. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
