Re: error 114
V Thu, 3 Oct 2019 06:32:48 -0600
napsáno:
> fetchmail fails when openssl reports an error 114 (I think)
Actually it doesn't.
> stat("/etc/ssl/certs/4a6481c9.0", {st_mode=S_IFREG|0644,
> st_size=1354, ...}) = 0 openat(AT_FDCWD, "/etc/ssl/certs/4a6481c9.0",
> O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=1354, ...}) = 0
> read(4, "-BEGIN CERTIFICATE-\nMIID"..., 4096) = 1354
> read(4, "", 4096) = 0
> close(4)= 0
> stat("/etc/ssl/certs/4a6481c9.1", 0x7ffefc274100) = -1 ENOENT (No
> such file or directory) write(1, "fetchmail: SSL verify callback
> d"..., 71) = 71 write(1, "fetchmail: Certificate chain, fr"..., 70) =
> 70 write(1, "fetchmail: Issuer Organization: "..., 43) = 43
> write(1, "fetchmail: Issuer CommonName: Gl"..., 41) = 41
> write(1, "fetchmail: Subject CommonName: G"..., 42) = 42
> write(1, "fetchmail: SSL verify callback d"..., 71) = 71
> write(1, "fetchmail: Certificate at depth "..., 35) = 35
> write(1, "fetchmail: Issuer Organization: "..., 43) = 43
> write(1, "fetchmail: Issuer CommonName: Gl"..., 41) = 41
> write(1, "fetchmail: Subject CommonName: G"..., 42) = 42
> write(1, "fetchmail: SSL verify callback d"..., 71) = 71
> write(1, "fetchmail: Server certificate:\n", 31) = 31
> write(1, "fetchmail: Issuer Organization: "..., 54) = 54
> write(1, "fetchmail: Issuer CommonName: GT"..., 41) = 41
> write(1, "fetchmail: Subject CommonName: p"..., 45) = 45
> write(1, "fetchmail: Subject Alternative N"..., 51) = 51
> write(1, "fetchmail: pop.gmail.com key fin"..., 90) = 90
> fstat(2, {st_mode=S_IFREG|0644, st_size=6732357, ...}) = 0
> write(2, "fetchmail: pop.gmail.com fingerp"..., 52) = 52
> write(3, "\25\3\3\0\2\2P", 7) = 7
> write(2, "fetchmail: OpenSSL reported: err"..., 114) = 114
>
> What is an error 114?
114 isn't an openssl error number, it's the amount of bytes the write()
syscall wrote.
Run strace -s1024 to get the whole error string.
> Why does openssl look for
> /etc/ssl/certs/4a6481c9.1 ? All the hashes for my certs end in .0
During c_rehash, if a certificate object has the same hash value as an
existing one, the last digit number is incremented to distinguish it.
So by looking for 4a6481c9.1, openssl is checking against a possible
conflict in the hashes.
> russell bell
Vita
--
Vítězslav Čížek Emergency Update Team (EMU)
"Consider it fixed."
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
Hi, V Fri, 18 Jan 2019 01:33:20 + "Jordan Brown" napsáno: > On 1/14/2019 4:09 AM, Matt Caswell wrote: > > This works more "by accident". There is no ciphersuite alias called > > "TLSv1.3", so using it as above results in no ciphersuites matched. > > Since the TLSv1.3 ciphersuites are on by default anyway that's all > > that you get back. > > > From what you say, and based on experimentation, it seems like the > TLSv1.3 ciphersuites are enabled even if you explicitly say to > disable them. > > $ openssl ciphers SHA384:\!TLS_AES_256_GCM_SHA384 > *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...] > > $ openssl ciphers AES:-SHA384 > *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...] > > That doesn't seem right. Am I missing something? Yes. TLS 1.3 ciphers are configured differently, you need to use the -ciphersuites option. See https://www.openssl.org/docs/man1.1.1/man1/ciphers.html Try # openssl ciphers -v -ciphersuites '' SHA384 Vita -- Vítězslav Čížek Emergency Update Team (EMU) "Whilst you sleep, we're probably saving the universe." -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Applying security patches to 0.9.8a
Hi, On Tue, 17 Apr 2018 18:36:09 -0400 "Rob Marshall" wrote: > The OS is SLES 10 SP3 and there are currently close to 80 binaries > that appear to use libssl.so.0.9.8. They are from a bunch of different > packages, so I would imagine that updating to anything more recent > than 0.9.8 would be a major hassle and possibly not even possible. > > I did find openssl-0.9.8zh.tar.gz which was last modified in 2015 > which is way better than 0.9.8a which hasn't been touched since 2005. > I'm trying to install 0.9.8zh now to see if that works. > > But I know someone is going to ask: Can you apply all of the newer > security fixes to 0.9.8zh? So I'll ask...can I? Of course you can. But all the patches will fail to apply automatically, at least because of the recent source code reformat. You'll have to do it by hand. The good news is that most of the security vulnerabilities wouldn't affect 0.9.8a. Many were introduced in the newer functionality, such as elliptic curves, DTLS or new asm implementations. Btw, SUSE is still maintaining SLE-10 (and backporting all the security fixes) for some customers. If you have access to the support channels, perhaps you can ask them. -- Vítězslav Čížek Emergency Update Team (EMU) "Whilst you sleep, we're probably saving the universe." -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
