Re: [openssl-users] Seeding before RSA key generation
>This is not correct. Thanks for the corrections, Matt. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Seeding before RSA key generation
We disagree, and as I wrote the latest RNG code and docs, I'm biased (sic). I'll leave on that weak pun. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Wildcard: how are they correct?
Actually, for public CAs, the current standard (the CAB/F Basic Requirements) require (a), (b) or (c), and prohibit (d). The prohibition on (d) is stated indirectly as a prohibition against putting something that isn't the subjects validated public DNS name in CN. In practice, most public CAs use (a) for maximum backward compatibility. It should also be noted that it is a lot less than 20 years since the popular GNU wget utility started looking at subjectAltName. Lesser known tools may have been even slower to implement it. On 10/10/2018 08:54, Kyle Hamilton wrote: If subjectAltName exists, CN= is not evaluated. All the given examples should work. (The only exceptions are validators that haven't been current for more than 20 years.) None of the examples is correct. CN= should not even be included in the certificate. If it is, (d) is the closest to correct, if "hello world" is replaced by something meaningful to the identification or naming of the subject. -Kyle H On Tue, Oct 9, 2018 at 11:18 PM Walter H. wrote: Hello, which of these possibilities is the correct one? (a) CN=*.example.com and subjectAltName = DNS:*.example.com, DNS:example.com (b) CN=example.com and subjectAltName = DNS:example.com, DNS:*.example.com (c) CN=example.com and subjectAltName = DNS:*.example.com, DNS:example.com (d) CN=hello world and subjectAltName = DNS:example.com, DNS:*.example.com Thanks, Walter -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Two sessions in a single full handshake
s_client has -sess_out and -sess_in options that can be used to save session information to a file and read it in for a subsequent connection. Neither is used by default. -Ben On Sun, Sep 30, 2018 at 11:06:14AM +0800, John Jiang wrote: > Does s_client resume any session in the local session file? > > On Sun, Sep 30, 2018 at 3:19 AM Salz, Rich via openssl-users < > openssl-users@openssl.org> wrote: > > > > >- The debug logs display two "SSL-Session" blocks in a full handshake. > > > > Only one "SSL-Session" block is displayed in a resumption. > > > > Why does full handshake has two sessions? > > > > > > > > This is part of the TLS 1.3 standard. A server can send back multiple > > sessions, so that a client may resume with a different session, and > > therefore prevent an observer from “linking” two different activities. > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] CMS_verify provides empty output
On 10/10/2018 13:55, RudyAC wrote: Hello, when verifying a signed email with CMS_verify() the verification failed. That is not the main problem. My problem is that the out data is empty. Using the library I got following error: OpenSSL Error code all:<772382878d> OpenSSL Error code lib:<46d> OpenSSL Error code func: <154d> OpenSSL Error code reason: <158d> OpenSSL Error: error:2E09A09E:CMS routines:CMS_SignerInfo_verify_content:verification failure The mail body is base64 encoded. When verifying the email on console with "openssl cms -verify" there is no message output, only the error message : Verification failure 47883249174256:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278: 47883249174256:error:2E09809E:CMS routines:CMS_SignerInfo_verify:verification failure:cms_sd.c:775: Any hints are welcome The general assumption in OpenSSL is that if the signature is invalid, the contents is probably fake,false or invalid, and thus unwanted. This is generally true in cryptography, but for actual e-mail applications it may very well be desired to allow the user to ignore signature verification failures. If so, one could combine allowing the mail software to access the MIME message normally (as if the signature was some unknown MIME part) with a meaningful (human readable) form of the actual error message from verification (there is more than one way the verification can fail, and the desired human response would often differ). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl commandline client use
As with essentially all open source software, there is no warranty with OpenSSL. Having said that, people use the OpenSSL applications for all sorts of things, including what you are doing. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Two sessions in a single full handshake
* The debug logs display two "SSL-Session" blocks in a full handshake. Only one "SSL-Session" block is displayed in a resumption. Why does full handshake has two sessions? This is part of the TLS 1.3 standard. A server can send back multiple sessions, so that a client may resume with a different session, and therefore prevent an observer from “linking” two different activities. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Engines on Mac OS X
>The capi engine is still broken, however That is windows-only, using the MSFT CryptoAPI. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using random bytes only in openssl_encrypt versus real private key
>This begs the question: what does openssl_encrypt actually do with just a > string of random bytes passed as the "key". I can't find anything in the OpenSSL or PHP/openssl source code that clearly identifies any particular action There is no such name (git grep -I openssl_encrypt) in the OpenSSL source. This is some PHP function that is calling underlying OpenSSL. I would ask on the PHP forum(s) what it's doing. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Engines on Mac OS X
* Gotcha. But why doesn't it work on Mac? The CAPI engine uses Microsoft libraries that are part of windows. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Engines on Mac OS X
>Gotcha. In that case why does it get built on Mac? I.e., why doesn’t the build >process exclude it automatically? Beats me. It ends up being a zero-length object file, more or less. Perhaps Richard Levitte knows. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL version 1.1.0i make test fails - 80-test_cms.t
Running ‘make test’ for 1.1.0i fails with: Test Summary Report --- ../test/recipes/80-test_cms.t(Wstat: 256 Tests: 4 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=99, Tests=561, 83 wallclock secs ( 0.94 usr 0.23 sys + 49.59 cusr 22.30 csys = 73.06 CPU) Result: FAIL make[1]: *** [_tests] Error 1 make: *** [tests] Error 2 I first ran: ./Configure --prefix=/usr/local shared darwin64-x86_64-cc enable-ec_nistp_64_gcc_128 no-ssl2 no-ssl3 then make depend then: make test macOS X 10.7.5 Any suggestions? Thanks, James.-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] QNX 6.5 OpenSSL Build
You can add the "no-dso" option to the command line to avoid this feature, but you lose access to loading engines. -- -Todd Short // tsh...@akamai.com<mailto:tsh...@akamai.com> // "One if by land, two if by sea, three if by the Internet." On Sep 16, 2018, at 1:04 PM, Viktor Dukhovni mailto:openssl-us...@dukhovni.org>> wrote: On Sep 16, 2018, at 11:44 AM, Murugaiyan Perumal via openssl-users mailto:openssl-users@openssl.org>> wrote: dso_dlfcn.c:84:12: fatal error: dlfcn.h: No such file or directory # include http://www.qnx.com/developers/docs/6.5.0/topic/com.qnx.doc.neutrino_lib_ref/d/dlopen.html This header is expected to be present, perhaps your system is missing the requisite software development package, or GCC-specific headers. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Re-enable 3DES on NGINX + OpenSSL 1.1.1
3DES is considered to only be 112 bits in strength. The default security level is 1 (which allows most things), perhaps nginx resets the security level to 3 or greater (which means a minimum of 128-bit ciphers). -- -Todd Short // tsh...@akamai.com<mailto:tsh...@akamai.com> // "One if by land, two if by sea, three if by the Internet." On Sep 17, 2018, at 4:20 PM, Neil Craig mailto:neil.cr...@bbc.co.uk>> wrote: Thanks very much Matt. I have indeed built with NGINX configure opt --with-openssl-opt=enable-weak-ssl-cipher and whilst I don¹t see an error when running NGINX with a/some 3DES cipher(s) in the ciphers list, I don¹t see any 3DES ciphers in the output of e.g. Testssl and I can¹t make a connection to the server using openssl CLI with -cipher <3DES cipher>. I wonder if the problem might be either NGINX not respecting/processing the configure opt (above) or possibly removing 3DES ciphers for some reason with openssl 1.1.1. I¹ll keep digging, thanks again for your help and for confirming that¹s the right thing to do. Cheers Neil Craig Lead Technical Architect | Online Technology Group Broadcast Centre, London W12 7TQ | BC4 A3 Twitter: https://twitter.com/tdp_org On 17/09/2018, 17:41, "openssl-users on behalf of Matt Caswell" mailto:openssl-users-boun...@openssl.org> on behalf of m...@openssl.org<mailto:m...@openssl.org>> wrote: On 17/09/18 16:29, Neil Craig wrote: Hi all I'm trying to re-add 3DES support (a temporary move, due to business requirements) to an NGINX (1.15.3) + OpenSSL (1.1.1) build via the NGINX build flag --with-openssl-opt=enable-weak-ssl-ciphers which i learnt from https://www.openssl.org/blog/blog/2016/08/24/sweet32/. Whilst I do see some older ciphersuites being offered by NGINX after doing this, e.g. Camelia, Seed and so on, i don't see 3DES. I was expecting to be able to specifically list 3DES e.g. via DES-CBC3-SHA but that didn¹t work. I have also tried adding @seclevel=0 to the ciphersuite string in NGINX but again, that didn¹t work, I don¹t see any 3DES ciphersuites available in NGINX. I'm wondering whether something changed between the above article and the final version of OpenSSL 1.1.1? (I.e. Whether 3DES support was completely removed in OpenSSL 1.1.1). Any pointers would be very much appreciated, I can¹t find anything very useful on the web. 3DES is still available in 1.1.1 but is no longer in the DEFAULT ciphersuite list, so unless you explicitly configure them to be available you won't see them (even if you configure with enable-weak-ssl-ciphers). E.g. (assuming you compiled with enable-weak-ssl-ciphers): $ openssl ciphers -v | grep 3DES Will give you 0 ciphers, but $ openssl ciphers -v 3DES | grep 3DES Should list 14 different 3DES ciphersuites that are available. I don't know about nginx config though so maybe someone else can help there. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users - http://www.bbc.co.uk<http://www.bbc.co.uk/> This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. - -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] updating openssl on MacOS
It's hard enough for the openssl team to document the basic config/build things, let alone all the operating systems and vendor-supplied stuff. Perhaps a wiki page, that the community could help maintain? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working
>The users who delay or block automatic updates tend to greatly overlap with the users who actively block remote telemetry of their update habits, thus skewing such statistics of "get almost full coverage within a month or two". But not downloads. :) Shrug. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Authentication over ECDHE
On 29/12/2018 14:19, C.Wehrmeyer wrote: I don't have access to the actual testing environments until Wednesday next year, so I've had to create a private account. > Which version of OpenSSL is this? (I don't remember if you said this > already). I'm not entirely sure, but I *think* it's 1.1.0. = OK, so I've been reading the mails before going to sleep and spent some time thinking and researching about this, and I've come to a conclusion: OpenSSL is a goddamn mess, SSL_clear() is pretty much superfluous, and as such shouldn't exist. Why? Well, to quote Viktor here: > DO NOT reuse the same SSL handle for multiple connections, And that is fricking bullshit. Not the quote itself or the suggestion - it's unlikely you had anything to do with the actual code - but the way things have been thought through (or rather, have not been thought through) by the library devs. I've written highly scalable libraries in the past before, and one thing you always want to do there is to trim fat. And "object allocation and initialisation" is something that you very much want to trim fat of, not only for obvious reasons such as malloc() and free() (or whatever OpenSSL uses as wrappers) being complexity monsters, but also for cache reasons (loading different cache line hurts performance). That's why you usually have functions like XXX_clear() or XXX_reset(), which do exactly that - prepare an object for another usage. memset() (or the OpenSSL equivalent of a secure memset) your allocated resources. I don't really see the problem here. Now add to that the fact that OpenSSL has been moving towards making its structures opaque, thus falling into the same trap that Microsoft has with COM and DirectX, and you can kind of see why, if you can't really determine anymore WHERE your object is going to be stored, you at least want to keep reusing it. This is not PHP, where people allocate memory all willy-nilly, or C++, where people don't even have shame anymore to use std::vector str_array instead of good old static const char*const str_array[] while expecting things to be made faster by invisible memory pools (and horribly failing at it), but C, where you want to think about each step quite carefully. Then OpenSSL even provides an SSL_clear function which is advertised like this: > SSL_clear - reset SSL object to allow another connection , and then, only later, in a big warning block, decides to tell the reader that this function only works when the stars align quite correctly and you've sacrificed at least two virgins, because: > The reset operation however keeps several settings of the last > sessions Then, as the documentation suggests, I read the entry for SSL_get_session: > The ssl session contains all information required to re-establish the > connection without a full handshake for SSL versions up to and > including TLSv1.2. In TLSv1.3 the same is true, but sessions are > established after the main handshake has occurred. And at this point it all falls apart. From my understanding OpenSSL keeps a session cache for servers so that key exchanges and protocol handshakes can be avoided. Problem is, *we're using ECDHE, where the last E stands for "ephemeral"*. In simple English: throw away the keys after you're done, we want to have forward secrecy. And then OpenSSL keeps a fresh copy of those for everyone who happened to be logged on at this point. Heartbleed apparently wasn't enough of a warning. Oh, but lets move everything to the heap so that it's more secure there now. I don't want to reuse a session with ephemeral keys; I want to reuse an object that is supposed to already have resources allocated for doing its job, as is indicated by the documentation of this function except for a small note at the end that tells you that the devs didn't really think about what "ephemeral" means. The session caching in the SSL and TLS protocols is to skip the expensive key exchange when reconnecting within a few seconds, as is extremely common with web browsers opening up to 8 parallel connections to each server. There is hopefully a configuration option to tell the OpenSSL server end SSL_CTX to not do this, just as there should (for multi-process web servers) be an option to hand the state storage over to the web server application for inter-process sharing in whatever the web server application (and its configuration) deems secure. Creating a new SSL object (EVEN FROM AN EXISTING SSL_CTX object) entails: - allocating the memory for the object itself on the heap (via OPENSSL_zalloc) - creating and managing a new lock for the object, and who knows for much more subobjects - creating a duplicate of the cipher suite stack (which isn't even a flat copy, but something that can cause the code to call OPENSSL_malloc *twice* in the worst case) - crea
Re: [openssl-users] How can I compile nginx with openssl to support 0-rtt TLS1.3
On 29/12/2018 07:42, carabiankyi wrote: Thanks for your advice. I get early data when I configure nginx ssl_early_data on. But I only get early data for get method. When using post method, the server terminate connection. Is it related with openssl? If so, how can I do to allow post method? TLSv1.x and SSL do not know or care what the HTTP commands are. It is probably nginx enforcing a security rule that 0-rtt data should not contain any potentially sensitive information, such as POST data. 0-rtt may be a reasonable way to more quickly transfer the URLs in the many GET requests for static web content such as images, javascript, video segments and user independent web pages. But it is too risky when handling requests for user specific or password protected content, because the 0-rtt would then be readable by an attacker even if the certificate check fails a few packets after the 0-rtt and associated decryption keys were already sent. Sent from my Samsung Galaxy smartphone. Original message From: Michael Wojcik Date: 29/12/2018 12:46 a.m. (GMT+06:30) To: openssl-users@openssl.org Subject: Re: [openssl-users] How can I compile nginx with openssl to support 0-rtt TLS1.3 > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Sent: Friday, December 28, 2018 00:25 > I have an nginx web server compiled with openssl that support TLS 1.3. What version of OpenSSL? Is it 1.1.1? The final version or an early release? Or 1.1.0, and if so, which letter release? > But when I test with firefox Nightly browser, it does not send early data together with > client hello packet. This sounds like an nginx or Firefox question. I haven't experimented with 0-RTT, which I think was a bad idea in TLSv1.3 and have no interest in enabling in my applications; but as I understand it, you have to set some options in the SSL structure (or the SSL_CTX you use to create it) in order to enable 0-RTT. That means nginx will have to make the necessary OpenSSL API calls. It may not have support for that yet, or in whatever version of nginx you're running. It's also possible that there's some issue with the Firefox build you're running and its 0-RTT support. My suspicion though is that nginx is not enabling 0-RTT in nginx. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Decrypting an OpenSSL encrypt AES256-CBC data
On 29/12/2018 13:41, Ertan Küçükoglu wrote: Hello, Windows program does not know length of data. I would like to use some kind of standard method and use exact method on Windows to decrypt. I think my problem is really that I do not know what "padding" is used by default. I have found below function. However, there is no detailed explanation about it in here: https://www.openssl.org/docs/man1.0.2/crypto/EVP_CIPHER_CTX_set_padding.html int EVP_CIPHER_CTX_set_padding(EVP_CIPHER_CTX *x, int padding); I wanted to learn what values can "padding" parameter be. I understand I can set it to zero ( 0 ) for disabling padding. This is not what I want because my plain text length is not confirmed to be multiply of 16 bytes. I can use PKCS#7 to decrypt on Windows so I would like to encrypt using that padding. Just do not know what value to pass in above function now. PKCS#7 also known as CMS or (in OpenSSL) SMIME, doesn't just pad. It generates a random key and encrypts it with the recipients key (usually a public key from a certificate, but there may be a symmetric variant). Thus to do PKCS#7 with OpenSSL, you need to use the "openssl cms" command line or the corresponding functions. Michael Wojcik <mailto:michael.woj...@microfocus.com>>, 28 Ara 2018 Cum, 21:16 tarihinde şunu yazdı: > From: openssl-users [mailto:openssl-users-boun...@openssl.org <mailto:openssl-users-boun...@openssl.org>] On Behalf Of Ertan Küçükoglu > Sent: Thursday, December 27, 2018 16:03 > A- I tried to directly decrypt (no padding applied) and I get my plain text plus > some additional invisible characters at the end. I am told it maybe a "padding" > issue, my problem, during decryption. How does the Windows program know how long the decrypted data is? It sounds to me like the problem is simply that your Windows code is decrypting the data correctly, then reading past it into garbage left at the end of the buffer. If the messages are of fixed length, only use that many bytes from the decryption output. If they're of variable length, then the sender will have to tell the receiver how long they are. There are many ways of doing that; you haven't told us enough about your protocol to know which would be appropriate in your case. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 manuals
They are there, but the sidenav needs to be updated. On 12/27/18, 11:31 AM, "Michael Richardson" wrote: If manual pages for 1.1.1 aren't going to be posted/generated: could https://www.openssl.org/docs/man1.1.1 redirect to https://www.openssl.org/docs/man1.1.0? (I think that 1.1.1 ought to be generated) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails [ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 manuals
On 27/12/2018 20:39, Dr. Matthias St. Pierre wrote:
Particularly if you don't know exactly what one is looking for...
{ There is something amiss with BIO_addr_rawaddress... it's shift right.
I don't see a problem in the HTML source though.. }
Sure, google will find some things, but usually it's the wrong version, and
one has to guess what the URL for the most recent one is.
At which point, like Dennis Clarke suggests, might as well grep the POD files
in the source code. This is not terribly effective to find information
about how to manipulate particular object types.
(I have started writing an index by object type for my own use, but I doubt
I'll get very far)
The manpages are primarily what the name says: manual pages. I.e, their
primary use is the unix/linux 'man' command.
The conversion to html is an add-on to make it available via web server.
And I agree with you that static web pages are not of much help, it could
be better, more searchable.
Consider at least including the one-line manpage summaries on the index
pages (the ones displayed by the apropos command on POSIX systems).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Authentication over ECDHE
> I didn't bother looking up what freeing entails - it's obvious to > anyone at this point that OpenSSL is a severe victim of feature creep, > that its memory allocation scheme is a mess, and long story short: I > will NOT free a perfectly fine object just because of incompetent > devs' chutzpah expecting their users to allocate memory dynamically en > mass for no goddamn reason whenever a new connection comes in. Fix > your goddamn code. Might I suggest that you fix your attitude? An insult and invective-filled polemic does no good. Perhaps you might find another library more to your liking; there are many available now. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How can I compile nginx with openssl to support 0-rtt TLS1.3
* But I only get early data for get method. * When using post method, the server terminate connection. Is it related with openssl? If so, how can I do to allow post method? Early data can be replayed. It is only safe to use early data when the request is idempotent, like GET. You might find https://tools.ietf.org/html/rfc8470 useful reading. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Authentication over ECDHE
On 29/12/2018 22:33, Richard Levitte wrote:
In message <20181229.170846.804158981742723988.levi...@openssl.org> on Sat, 29 Dec
2018 17:08:46 +0100 (CET), Richard Levitte said:
In message <38b97114-0c66-40ed-f631-58aa20940...@gmx.de> on Sat, 29 Dec 2018 14:19:47 +0100,
"C.Wehrmeyer" said:
...
What's wrong with that, you ask? Let me show you how I'd have done
that:
static const unsigned char ssl3_pad_1[] =
{
""
""
""
""
""
""
};
static const unsigned char*ssl3_pad_2[] =
{
""
""
""
""
""
""
};
So, no. I don't trust anyone. Especially not this mess of a code.
You do know that your string insert NUL bytes, right? If you have a
look at how they're used, you might see why those stray NUL bytes
aren't a good thing.
Never mind this remark... For some reason, my brain added commas
after each partial string. Meh...
It still inserts NUL bytes at the end of each array, changing
sizeof(array) as well as cache access patterns (and thus side
channel effects).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Question regarding OpenSSL compilations
Look at the tricks openssl has to do in order to properly zeroized memory and avoid having the compiler optimize it away. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Compiling FIPS-cable OpenSSL on Windows Server 2012R2
> On Jan 7, 2019, at 11:52, Chris Fernando via openssl-users > wrote: > >> >> On Jan 7, 2019, at 09:20, Chris Fernando via openssl-users >> wrote: >> >> I perused the list archives for all of 2018 and did not see anything current >> relating to this problem, so if this is a question that has been asked & >> answered, please feel free to point me at the relevant location to read >> about what I'm doing incorrectly. =) >> >> I'm not at all familiar with Windows & compiling Open Source projects, but I >> am having no trouble on Linux with OpenSSL + FIPS. On Windows, with Visual >> Studio 2017 (Community Edition), I am able to compile the FIPS 2.0.16 module >> and OpenSSL 1.0.2q (NO FIPS) without issue. >> >> [snip] >> >> >> I am doing the following to compile FIPS: >> cd c:\path\to\fips-source >> ms\do_fips no-asm >> >> I am doing the following to compile OpenSSL+FIPS (Strawberry Perl installed): >> cd c:\path\to\openssl-source >> nmake -f ms\ntdll.mak clean >> nmake -f ms\nt.mak clean >> perl Configure VC-WIN64A fips no-asm --with-fipsdir=c:\path\to\fips-source >> ms\do_win64a no-asm >> nmake -f ms\ntdll.mak >> >> [snip] > > > Well, I managed to get the compile to move a bit further by copying "inc32" > to "include", "util" to "bin", and "out32dll" to "lib" in the FIPS source > directory, that I was including in --with-fipsdir= . > > However, now I am getting the following error during the OpenSSL build > process. > > [snip] So, for anyone searching in the future, I managed to get it to compile ensuring the following: Ensure the following is installed: * Perl (I used Strawberry Perl 5.24.4.1) * NASM (I used 2.14.02) * MS Visual Studio 2017 Community with the MS Windows SDK (what I used) - Ensure your Windows PATH variable has NASM and Perl included (not including this is what was causing my errors). - Start the Visual Studio 'Developer Command Prompt'. - Change directory to the decompressed openssl source directory. - Follow the instructions in the OpenSSL FIPS User Guide. I had to ensure '--with-fipsdir=' pointed to where my FIPS object code was installed. It was, purposefully, not in C:\usr\local\ssl\fips-2.0\, which was also causing problems for me. I appreciate those who reached out to me directly to provide guidance in solving my compile issues. Thanks, Chris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] in the department of "ain't no perfect"
> like a way to extract the signature date from a CMS structure. With all the > opaque structs that have been introduced in the last few releases, it's not > clear to me how to do that. Any examples or guidance (other than don't do > that)? Can you list which fields you need and open an issue on github? Yes, this would be a bug-fix because "going opaque" made some things not possible. Thanks. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] in the department of "ain't no perfect"
On 16/01/2019 21:25, Viktor Dukhovni wrote: On Jan 15, 2019, at 10:29 AM, Eliot Lear wrote: I have an application that requires long-lived signatures, perhaps long past the point where the signer's cert has expired. I'd like a way to extract the signature date from a CMS structure. With all the opaque structs that have been introduced in the last few releases, it's not clear to me how to do that. Any examples or guidance (other than don't do that)? I doubt this has anything to do with opaque structures. The real issue here is that IIRC CMS (previously known as PKCS7) has no signature date. It just has to be signed data and a signature, with an X.509 certificate that has an expiration. There is a commonly implemented extension (the signingTime authenticated/signed attribute, RFC2985 section 5.3.3 and RFC2630 section 11.3) to store this. Microsoft tools show this as the date of the signature, separate from the date of any signed timestamp. There are also at least 3 common non-authenticated/unsigned attributes for storing time stamp results: Option A: OID 1.2.840.113549.1.9.6: An RFC2985 section 5.3.6 (RFC2630 section 11.4) countersignature where the countersigning certificate has the timestamping extended key usage and the countersignature has an authenticated/signed signingTime attribute. This form is used and expected by some Microsoft implementations, including backward compatible code signing. Option B: OID 1.2.840.113549.1.9.16.2.14: As defined in RFC3161 Appendix A. Option C: OID 1.3.6.1.4.1.311.3.3.1: The value of this attribute is a SET OF TimeStampToken (where each TimeStampToken is as defined in RFC3161). This form is used and expected by some Microsoft implementations, including current code signing features. In all 3 forms, the timestamp signs the encryptedDigest/signature in the SignerInfo having the attribute. The timestamp only authenticates the fact that the signature was made at or before the specified time, revocation information may be obtained and archived by the relying party (but contains its own timestamps and signatures). Note: The dual naming above is because RFC2630 CMS changed the names of various things relative to the otherwise identical definitions in PKCS#7. The 3 attributes are used with any version of CMS/PKCS#7, including version 1. For long-term storage, the date of interest is NOT when the object was signed, but when it was received, verified and stored. For that what you need is separate long-term integrity protection for the underlying object store, separate from the origin signatures on inbound objects, that need only be valid at time of import. Indeed with content that's also encrypted, you'll typically want to immediately decrypt it, decoupling it from a comparatively short-lived inbound encryption public key, and re-encrypt for storage under a key that is managed as part of the object store. For encrypted e-mail there is an obvious source of the date when the signed mail was locally stored (thus the signatures inside must have been created before that). This source is the reception/delivery timestamp recorded in the mail headers by your local trusted mail server or by equivalent code in your local POP3 client. This of cause won't work with an untrusted 3rd party hosted mail storage server, unless some trust can be assigned to that server. An important limitation is that some CAs prematurely discard historic revocation information for mail certificates, and that most mail clients and servers don't capture and store that information. The naïve model of using the signer and recipient keys as long-term verification and decryption keys is deeply flawed for data retention. This is a bit part of the reason why end-to-end email encryption has negligible adoption, the storage infrastructure to make it usable was never built. As explained above, most of that storage infrastructure is in fact in place, but the major e-mail clients lack the code to use it. For example the "openssl cms" command (used by some unix mail clients, such as Mutt) doesn't have an option to specify the "as of" date extracted from an external trusted source. Nor does it have an option to input a recorded OCSP response or CRL to be validated and used according to that "as of" date. A much bigger hindrance is the significant difficulty of finding 3rd party e-mail CA services, as those tend to be buried in weird corners of CA sites or overly entangled with specific services such as citizen ID for specific countries (typically allowing only one non-secret e-mail address per person). To clarify, I have found at least one useful service, but it was by no means easy. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Managemen
Re: [openssl-users] Multiple client connection to Nginx server
On 12/12/2018 12:54, ASHIQUE CK wrote: Hi, Any help on this ? On Wed, Dec 12, 2018 at 3:03 PM ASHIQUE CK <mailto:ckashique...@gmail.com>> wrote: Hi, We are using a Crypto Accelerator Engine to offload AESGCM and RSA parameters. Trying to connect multiple clients simultaneously with a single Nginx server, which is using this accelerator. The Key and IV is passing only at handshake, and after handshake this set of key and IV is using for all encryption and decryption. So at Engine side, we are storing this Key and IV to a buffer and while encrypting/decrypting , this Key and IV is used from this buffer. But, while multiple client connects, the last saved Key/IV is getting for all clients. So, is there any way to get a unique ID foer each client connection ? The following assumes that the accelerator is accessed using an OpenSSL "engine" plugin, if instead you are inserting code in NGINX to hand over the complete SSL/TLS record processing to the hardware, then a different approach is needed. OpenSSL Crypto Engines are not limited to SSL/TLS but can be used for other tasks using the OpenSSL libcrypto library. Thus the way this works is that the SSL/TLS requests an EVP "handle" for each key that it wants to use, this handle then maps (indirectly) to a structure passed to the engine, which is unique to each key. A correctly implemented engine is supposed to use that structure to tell the difference between different keys stored in the actual hardware. For the case of GCM key/IV pairs, it may be that in some situations OpenSSL requests more than one EVP key instance for the same key, typically to allow each to have its own independent state (for GCM, this is the counter, for CBC it would be the IV chaining from block to block). The simple solution is to just treat them as different keys, but if this uses too many hardware key storage locations, an engine may use some way to recognize the reused key, share the hardware object and keep count of how many "handles" point to that key. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Delay in converting CRL to binary data
Hello, We are converting a *CRL* (Size *3.687 MB*) to binary data using *X509_CRL_get_REVOKED()* and it is taking *167.977* seconds to process the same. Please let us know if this is an expected behavior or something should be done to improve the above observation. With Regards, Prateep -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Openssl version in RHEL 8
* [root@puoasvorsr07 ~]# openssl version * OpenSSL 1.1.1 FIPS 11 Sep 2018 Is that a version you built yourself, or from RedHat? I believe it is RedHat’s version, which did their own FIPS work. The OpenSSL FIPS module is starting development. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] A script for hybrid encryption with openssl
On 17/12/2018 16:21, Nick wrote: Hello, I've written a script to try and work around openssl's lack of a way to encrypt large files with public key or hybrid cryptography. I gather SMIME works for files < ~ 2.5GB but the current implementation cannot decrypt files larger than this. My use case is automated server back-ups, for which I need to back up arbitrarily large files and copy the result to S3 for storage, but I don't want to store a decryption key on the server. I contemplated splitting the archives, except this seemed about as much work as writing something which stored an encrypted one-time password with the payload and using symmetric encryption. As I'm not really a crypto/security expert, I thought I'd post it here and ask for some feedback on it. https://github.com/wu-lee/hencrypt A simpler way is to realize that the formats used by SMIME/CMS (specifically the PKCS#7 formats) allow almost unlimited file size, and any 2GiB limit is probably an artifact of either the openssl command line tool or some of the underlying OpenSSL libraries. It would be interesting to hear from someone familiar with that part of the OpenSSL API which calls to use to actually do CMS signing/encryption (and verification/decryption) of data too large to fit in available memory, and how to handle the data length BER encoding for values larger than a size_t. Anyway, setting up an alternative data format might be suitable if combined with other functionality requiring chunking, such as recovery from lost/corrupted data "blocks" (where each block is much much larger than a 1K "disk block"). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] FIPS module v3
Hi everyone, I have been following OpenSSL blog and know that work on new OpenSSL FIPS module has started. Current FIPS module (v.2) has end of life (December 2019) and I assume that new FIPS module will be by that time. but can someone tell me - is there are approximate dates - will it be available earlier? thanks,Alibek -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Delay in converting CRL to binary data
Hello, Please let me know if we have any update on this. With Regards, Prateep On Thu, Dec 13, 2018 at 2:26 PM Prateep Kumar wrote: > Hello, > > We are converting a *CRL* (Size *3.687 MB*) to binary data using > *X509_CRL_get_REVOKED()* and it is taking *167.977* seconds to process > the same. > > Please let us know if this is an expected behavior or something should be > done to improve the above observation. > > With Regards, > Prateep > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] PerlASM for x64
On 24/12/2018 19:08, Richard Levitte wrote: In message <3fc4d543-d71a-8c22-566a-d902c4f7d...@gmail.com> on Mon, 24 Dec 2018 13:17:51 +0100, Gisle Vanem said: Richard Levitte wrote: I experimented some more. I figured the "auto" does not work. But this works: perl crypto\aes\asm\aesni-x86_64.pl nasm > tmp-file.s diff tmp-file.s crypto\aes\aesni-x86_64.asm No diffs. Why does the the generation of .asm-files be so damn hard to figure out? Some cmd-line help to show what "auto" does would be nice. The "auto" flavor takes note of the output file extension. .asm vs .s in this case. Thank, but it was a typo in my 1st email. The correct command was with a redirect: set ASM=nasm f:\util\StrawberryPerl\perl\bin\perl crypto\aes\asm\aesni-x86_64.pl auto > tmp-file.s That isn't a correct use of the script. All of the assembler perl scripts expect the output file as last argument, and the x86_64 ones do look at the output file and determines that if the extension is '.asm', nasm assembler is expected, otherwise you will get gas assembler. So if you redirect, the result is, mildly put, undefined. Thank you, though... it is time the assembler stuff gets documented, and I think I'm in a fairly good position to do so. I will not promise that it will happen fast, but it is in my backlog. As a trivial (and easily audited first patch) perhaps make the common code error out with a usage message to STDERR if the command line makes no sense (no output file, wrong argument count, auto with unrecognized file extension). Ideally this would be in the common perl module(s), not in individual assembler files. Remember that keeping every patch easily audited by the wider community is essential to the trustworthiness of OpenSSL, the great reformatting a while back was a major mistake in this regard. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL v1.1.1 static library size reduction
* Please find the above previous mail. I am not sure what this means. I guess you are referring to earlier email in the thread. I gave you my suggestion, good luck. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Delay in converting CRL to binary data
* Please let me know if we have any update on this. This is a volunteer effort. :) My *GUESS* is that the CRL data isn’t sorted, and it’s doing a linear search. You should profile the code to find out where, exactly, all the time is being spent. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] AES encrypt expanded key is different with no-asm
On 10/12/2018 11:30, Hemant Ranvir wrote:
Dear all,
After extracting openssl-1.1.1.tar.gz, openssl can be configured
without asm by passing no-asm flag during config command.
The expanded key can be obtained like follows:
//Getting expanded key from inside openssl
//Copied from crypto/evp/e_aes.c
typedef struct {
union {
double align;
AES_KEY ks;
} ks;
block128_f block;
union {
cbc128_f cbc;
ctr128_f ctr;
} stream;
} EVP_AES_KEY;
EVP_CIPHER_CTX *cipher_ctx = ssl->enc_write_ctx;
EVP_AES_KEY * cipher_data = EVP_CIPHER_CTX_get_cipher_data(cipher_ctx);
printf("Encrypted Expanded Key is : ");
for(i=0;i<((cipher_ctx->cipher->key_len)/sizeof(cipher_data->ks.ks.rd_key[0])*11);i++)
{
printf("%08x", cipher_data->ks.ks.rd_key[i]);
}
printf("\n");
To get the 128 bit encrypted key :
unsigned char* key = unsigned char* malloc(16);
int i;
for (i=0; i<4; i++) {
key[4*i] = cipher_data->ks.ks.rd_key[i] >> 24;
key[4*i+1] = cipher_data->ks.ks.rd_key[i] >> 16;
key[4*i+2] = cipher_data->ks.ks.rd_key[i] >> 8;
key[4*i+3] = cipher_data->ks.ks.rd_key[i];
}
I am using this 128 bit key and using it in *Rijndael* Key Schedule
function to get the expanded key. The expanded key will be 128*11 bit
long.
This expanded key is equal to the expanded key obtained from accessing
structures inside openssl(shown in section "Getting expanded key from
inside openssl" ) which is expected.
Now if I configure openssl without no-asm flag and get the expanded
key from inside openssl and compare it with the expanded key
calculated using the function I wrote. They are not equal. As far as I
know there is only one way to calculate expanded key. I have even
checked whether the expanded key inside openssl is inverse cipher
expanded key but yet it is different.
Can someone point me in the right direction.
Thanks!
There have always been multiple ways to store the expanded AES
key, each optimized a different implementation of the inner
loops in the encryption block function. It is highly likely
the assembler implementation for any given processor uses a
different inner loop, and thus a different expanded key data
layout, than the generic C code.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
On 10/12/2018 14:41, Michael Wojcik wrote: From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Michael Ströder Sent: Saturday, December 08, 2018 06:59 On 12/7/18 11:44 PM, Michael Wojcik wrote: Homograph attacks combined with phishing would be much cheaper and easier. Get a DV certificate from Let's Encrypt for anazom.com or amazom.com, or any of the Unicode homograph possibilies> Part of the point of EV certificates was supposed to be making the difference in trust visible to end users. And how do you avoid such homograph attack on subject DN attribute "O" (organization's name) when display the holy EV green sign? => EV certs also don't help in this case. Also in case of amazon.com most users know the pure domain name but not the *exact* company name, not to speak of the multitude of names of all the subsidiaries. Oh, I agree (at least on the latter point - I'm not sure how concerned I am about homograph attacks on the subject DN, since the common UAs are verifiying subjAltName values and ignoring the DN). That's why I wrote "was *supposed* to be". I don't think EV certificates accomplished this goal. I've never felt EV certificates were very useful, and they got progressively worse over time. Remember back in July when Entrust's Chris Baily put language on the CA/BF ballot (Ballot 255, specifically, if anyone wants to look it up) to restrict EV certificates to entities that had been incorporated for at least 18 months? That's the kind of terrible thinking that the EV process produced. The Stripe certificate fiasco that led to Baily's proposal is another example of why EV certificates Just Don't Work. The idea of having different certificates at different trust levels might be salvageable, but the EV implementation put the burden of evaluating those trust levels on the user (because user agents just passed it on to them), and the vast majority of users aren't in any position to do that. Nor were they in any position to determine how those trust levels ought to affect their threat model (that was the hole exploited by the Stripe attack). A site with a legitimate EV certificate might still misrepresent itself, perform hostile actions, or be vulnerable to attack (or already subverted) - EV says nothing about those risks. The Stripe certificate fiasco relied heavily on browsers not displaying the EV certificate fields (specificlly Jurisdiction of incorporation) correctly along with the name, as clearly spelled out in the EV specification. That Jurisdiction field along with the uniqueness checks done by the authorities of the jurisdiction is what is supposed to prevent homographs in the O field. For example, using Cyrillic letters in a de jure company name is unlikely to be allowed outside the Cyrillic using jurisdictions (former USSR, Serbia, maybe Bosnia and Montenegro). If displayed, users should readily notice the wrong country in the green bar. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] RSA Public Key error
Bonjour, Assuming the first 24 bytes you’re talking about are the very beginning of the SPKI structure (that is, the enclosing SEQUENCE, and the AlgorithmIdentifier), that means you’ve replaced up to the first byte of the BITSTRING containing the public key (this byte indicates the number of unused bits) for a 2048bits RSA key with 16 custom bytes. That’s perfectly normal for OpenSSL to refuse to load that beast, and for asn1parse to return errors (the first bytes do not represent a correct DER encoding of anything). Think of it as « I took a Jpeg file, replaced some bytes at the beginning by my own, and now I can’t open the file again ». Those bytes are there for a reason. A quick solution would be to *add* your 16 bytes before the public key, and remove them when passing the rest of the bytes to OpenSSL. Cordialement, Erwann Abalea De : openssl-users au nom de prithiraj das Répondre à : "openssl-users@openssl.org" Date : mercredi 12 décembre 2018 à 08:08 À : "openssl-users@openssl.org" Objet : [openssl-users] RSA Public Key error Hi, I have a RSA public key(PKCS 1v1.5) that I have obtained from somewhere. That key has been obtained after removing the first 24 bytes from the originally generated RSA public key. Those 24 bytes are being replaced by some custom 16 byte information which is being used as some sort of identifier in some future task and those 16 bytes are playing no role in encryption. OpenSSL fails to read this key. asn1parse shows some parsing error and most importantly RSA encryption in OpenSSL using this key fails. The untampered version of the RSA public key generated from the same source and containing the original 24 bytes at the beginning of the key is successfully read by OpenSSL and the RSA encryption using that key is also successful in OpenSSL. But our requirement is to use the first key containing the custom 16 byte information. My understanding is that the first 24 bytes of RSA public key following PKCS standards doesn't contain the modulus and exponent details required for RSA encryption. But OpenSSL seems to require these 24 bytes for encryption. Can someone please confirm what kind of information is present in the first 24 bytes of RSA Public key and/or why does OpenSSL need it? If possible, please suggest a solution to work with that RSA public key containing custom 16 byte information at the beginning of the key. Thanks and Regards, Prithiraj -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] RSA Public Key error
Bonjour, Without knowing what functions you’re calling when you try to encrypt data using the key Key3_wo16, I can only guess. And I’m guessing that you’re calling a function that expects to find a public key encoded in a SubjectPublicKeyInfo structure, and since this Key3_wo16 object is not such a structure, the function fails. What you can do is : * Take your public keys (for example Key2_w16) * Check that the first 16 bytes are what you expect to have * Pass the remainder of the file to the d2i_RSAPublicKey() function * Use the resulting RSA public key the way you want Cordialement, Erwann Abalea De : prithiraj das Date : lundi 17 décembre 2018 à 08:23 À : Erwann Abalea , "openssl-users@openssl.org" Objet : Re: [openssl-users] RSA Public Key error Hi Erwann/All, Thank you for your earlier response. I have done a couple of tests on the originally generated 2048-bit RSA public key (let's say Key1_org) and the key file containing 16 byte custom information after removing 24 bytes from the originally generated key file and prepending those 16 bytes (let's say Key2_w16). For my experiment(s), I also removed those 16 bytes from the key Key2_w16 (which contains custom information) and the rest of the bytes were written into a file. Lets name this keyfile Key3_wo16. I believe the presence of custom 16 byte information resulted in asn1parse encoding/decoding errors as mentioned in the previous mail.. So now, Key3_wo16 = Key2_w16 - the first 16 bytes = Key1_org - the first 24 bytes. And I performed asn1parse on Key3_wo16. The output of asn1parse on this key is shown in the image file asn1parse of 24 byte removed.jpg which is attached in the mail. And I also performed 2 asn1parse strparse opertions on the originally generated public key Key1_org with strparse offsets 19 and 24. I have attached screenshots of the same with names asn1parse strparse 19.jpg and asn1parse strparse 24.jpg respectively. The outputs in all cases are the same. In the screenshots, the (removed/blurred) respective INTEGER values in all screenshots are the same. What I want to know is why is OpenSSL throwing an error when try to encrypt data using the key Key3_wo16? The same command used for encryption works when the key Key1_org is used. I believe the INTEGER values contain the modulus and exponent information and so, I was expecting the encryption to be successful but OpenSSL fails to accept this key. Can anyone please tell me what is going wrong here? Apart from the solution suggested by Erwann , can anyone please suggest an alternative solution as we need to work with the Key2_w16 ( the key containing the custom 16 byte information after removing the originally present first 24 bytes)? That is the only keyfile received by us. Thanks and Regards, Prithiraj On Wed, 12 Dec 2018 at 12:32, Erwann Abalea via openssl-users mailto:openssl-users@openssl.org>> wrote: Bonjour, Assuming the first 24 bytes you’re talking about are the very beginning of the SPKI structure (that is, the enclosing SEQUENCE, and the AlgorithmIdentifier), that means you’ve replaced up to the first byte of the BITSTRING containing the public key (this byte indicates the number of unused bits) for a 2048bits RSA key with 16 custom bytes. That’s perfectly normal for OpenSSL to refuse to load that beast, and for asn1parse to return errors (the first bytes do not represent a correct DER encoding of anything). Think of it as « I took a Jpeg file, replaced some bytes at the beginning by my own, and now I can’t open the file again ». Those bytes are there for a reason. A quick solution would be to *add* your 16 bytes before the public key, and remove them when passing the rest of the bytes to OpenSSL. Cordialement, Erwann Abalea De : openssl-users mailto:openssl-users-boun...@openssl.org>> au nom de prithiraj das mailto:prithiraj@gmail.com>> Répondre à : "openssl-users@openssl.org<mailto:openssl-users@openssl.org>" mailto:openssl-users@openssl.org>> Date : mercredi 12 décembre 2018 à 08:08 À : "openssl-users@openssl.org<mailto:openssl-users@openssl.org>" mailto:openssl-users@openssl.org>> Objet : [openssl-users] RSA Public Key error Hi, I have a RSA public key(PKCS 1v1.5) that I have obtained from somewhere. That key has been obtained after removing the first 24 bytes from the originally generated RSA public key. Those 24 bytes are being replaced by some custom 16 byte information which is being used as some sort of identifier in some future task and those 16 bytes are playing no role in encryption. OpenSSL fails to read this key. asn1parse shows some parsing error and most importantly RSA encryption in OpenSSL using this key fails. The untampered version of the RSA public key generated from the same source and containing the original 24 bytes at the beginning of the key is successfully read by OpenSSL and t
Re: [openssl-users] FIPS module v3
thanks for your reply! On Tuesday, 18 December 2018, 20:57:40 GMT, Paul Dale wrote: There are no committed to dates of any kind at present. The project is underway but it is too early to set a schedule, yet alone a completion date. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia From: Alibek Jorajev via openssl-users [mailto:openssl-users@openssl.org] Sent: Tuesday, 18 December 2018 8:10 PM To: openssl-users@openssl.org Subject: [openssl-users] FIPS module v3 Hi everyone, I have been following OpenSSL blog and know that work on new OpenSSL FIPS module has started. Current FIPS module (v.2) has end of life (December 2019) and I assume that new FIPS module will be by that time. but can someone tell me - is there are approximate dates - will it be available earlier? thanks, Alibek -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL v1.1.1 static library size reduction
If all you need is RSA then you will probably find it easier to write a makefile of your own. You will have to do multiple builds to get all the missing pieces, such as the BN facility, the memory allocation, the error stack, etc. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Authentication over ECDHE
>While certificate-less TLS is in theory possible with RFC7250 bare public > keys Pre-shared keys (PSK) don't require certs, maybe that meets the need. A thing to know about PSK is that each side is fully trusted, and if one side gets the key stolen, then the thief can pretend to be either side. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Subject CN and SANs
Putting the DNS name in the CN part of the subjectDN has been deprecated for a very long time (more than 10 years), although it is still supported by many existing browsers. New certificates should only use the subjectAltName extension. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Subject CN and SANs
> >. New certificates should only use the subjectAltName extension. >Are any CAs actually doing that? I thought they all still included > subject.CN. Yes, I think commercial CA's still do it. But that doesn't make my statement wrong :) -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] GSCheck fails for Windows 32build 'libeay32.dll' library
Hi All, The 32bit OpenSSL 1.1.0i library 'libeay32.dll' fails for binscope GSCheck on Windows. E:\libeay32.dll: error BA2022: libeay32.dll was compiled with the following modules for which a language could not be identified. Ensure these were compiled with debug information and run BinScope again: aes-586.obj aesni-x86.obj bf-586.obj bn-586.obj chacha-x86.obj cmll-x86.obj co-586.obj crypt586.obj des-586.obj ecp_nistz256-x86.obj ghash-x86.obj md5-586.obj poly1305-x86.obj rc4-586.obj rmd-586.obj sha1-586.obj sha256-586.obj sha512-586.obj vpaes-x86.obj wp-mmx.obj x86-gf2m.obj x86-mont.obj x86cpuid.obj Any idea on how to resolve this problem or is it expected behavior. NOTE: 1. Adding /GS flag and enabling debug mode did not resolve the problem. 2. The same works fine with 64bit Windows 'libeay32.dll' 3. For other OpenSSL library ' libssl32.dll', GSCheck passes for both 32bit and 64bit. Regards, Vinay -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [EXTERNAL] Re: Self-signed error when using SSL_CTX_load_verify_locations CApath
On Fri, 2018-11-30 at 23:55 +, Michael Wojcik wrote: > > "Self-signed certificate in certificate chain" does not to me > > > convey "No > > > certificate hash links" (or "CA certificate not found in hash > > > links"). > > > Viktor's points are all good ones, but considering how often this > particular message causes confusion for users and developers (at > least in my experience), I wonder whether changing the text to > "Untrusted self-signed certificate in certificate chain" would help. > That would suggest to the user that the problem might be an issue > with the trust store. > My .02: The message "Self-signed certificate in certificate chain" does make it sound like OpenSSL rejected the certificate precisely because it's self signed, and not because it's an untrusted root certificate. I would suggest a less misleading reason, at least. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OCSP response signed by self-signed trusted responder validation
Perhaps you can build a trust store to handle your needs. I am not sure. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OCSP response signed by self-signed trusted responder validation
The responder isn’t supposed to be self-signed. It’s supposed to be signed by the CA issuing the certs. That way you know that the CA “trusts” the responder. Now, having said that, what you want to do is reasonable – think of it as “out of band” trust. You will probably have to modify the source to support it, however. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [EXTERNAL] Re: Self-signed error when using SSL_CTX_load_verify_locations CApath
On 01/12/2018 21:53, Viktor Dukhovni wrote: On Sat, Dec 01, 2018 at 07:12:24PM +, Michael Wojcik wrote: Are there compatibility concerns around changing error message text for which users may have created regex patterns in scripts? I agree the text could be better, but not sure in what releases if any to change the text, since the change may cause issues for some users. Sure, this is always a concern. Maybe the change could be considered for OpenSSL 3.0, since that's a major release. Care to create a PR against the "master" branch? Something along the lines of: "Provided chain ends with untrusted self-signed certificate" or better. Here "untrusted" might mean not trusted for the requested purpose, but more precise is not always more clear. Perhaps s/untrusted/unknown/ as in "Provided chain ends with unknown self-signed certificate". Or even better, two different error codes: - "Only self-signed end certificate provided" - "Provided chain ends with unknown root certificate" (Deciding which one keeps the old error code is left as an exercise). (Distinguishing a self-siged end cert from a self-signed root when no other certificate is provided is also left as an exercise). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [EXTERNAL] Re: Self-signed error when using SSL_CTX_load_verify_locations CApath
On Sat, 2018-12-01 at 15:53 -0500, Viktor Dukhovni wrote: > On Sat, Dec 01, 2018 at 07:12:24PM +, Michael Wojcik wrote: > > > > Are there compatibility concerns around changing error message > > > text for which users may have created regex patterns in scripts? > > > > > > I agree the text could be better, but not sure in what releases > > > if any to change the text, since the change may cause issues > > > for some users. > > > > Sure, this is always a concern. Maybe the change could be > > considered for OpenSSL 3.0, since that's a major release. > > Care to create a PR against the "master" branch? Something > along the lines of: > > "Provided chain ends with untrusted self-signed certificate" > > or better. Here "untrusted" might mean not trusted for the requested > purpose, but more precise is not always more clear. Just wondering, is there a different error for an untrusted cross- signed root? If it's the same error, then maybe remove "self-signed" from the above message too, because that would not always be the case either. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [EXTERNAL] Re: Self-signed error when using SSL_CTX_load_verify_locations CApath
On 05/12/2018 00:50, Viktor Dukhovni wrote: On Tue, Dec 04, 2018 at 04:15:11PM +0100, Jakob Bohm via openssl-users wrote: Care to create a PR against the "master" branch? Something along the lines of: "Provided chain ends with untrusted self-signed certificate" or better. Here "untrusted" might mean not trusted for the requested purpose, but more precise is not always more clear. Perhaps s/untrusted/unknown/ as in "Provided chain ends with unknown self-signed certificate". I don't see why "unknown" is better, it could under certain conditions be "known", but not trusted. Unknown would differ from untrusted in cases where there is some setting indicating that some certificates in the CA directory are trusted only for some/no purposes. This could (in current or future code) represent things such as the trust bits in "Trusted Certificate" files. Or even better, two different error codes: - "Only self-signed end certificate provided" - "Provided chain ends with unknown root certificate" That already exists: crypto/x509/x509_txt.c: case X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT: return "self signed certificate"; case X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN: return "self signed certificate in certificate chain"; In that case, maybe change the text to: "Provided chain ends with an unknown and thus untrusted root certificate" This would capture both the fact that the root is unknown (not in the CA stores configured/loaded) and that this is the specific fact causing it to be untrusted. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
On 06/12/2018 21:16, Viktor Dukhovni wrote: On Dec 6, 2018, at 3:06 PM, Blumenthal, Uri - 0553 - MITLL wrote: So, a CA that's supposed to validate its customer before issuing a certificate, may do a "more sloppy job" if he doesn't cough up some extra money. I think Peter is exactly right here. CA either do their job, or they don't. If they agree to certify a set of attributes, they ought to verify each one of them. No, Uri you get it wrong. Different levels of certainty is the point. Consider it like this: DV: A regular printed business card that you can get from a vending machine, proves very little. The CA just checks that the person or robot requesting the certificate has some semblance of control over the domain name at the time of issuance. Price is as low as $0. OV: A debit card with the supposed owners name on it, available from a number of companies that do minimal checking, but still a better ID proof than a business card. The CA must check that the company name and address are true, using some basic steps such as checking that a company by that name exists at that address and confirms they are the ones requesting the certificate. There is no check that the company name is an official name or that the company has a business license etc. A traditional lemonade stand run by children can potentially get an OV certificate if they stay in one place for the time it takes to get the certificate. (A CA agent visiting the company site is enough checking of company existence for OV). EV: A proper photo ID with serious identity checking before being issued, like a government passport. Includes the holders legal name and government ID number (literally), which can be used to look up the subjects legal status. The CA must check public records, and do some hard checks that the request is officially from that company. There is a 50+ pages official specification listing how every tidbit of this information must be checked. The CA cannot limit its own liability for certain failures to less than $2000. Each step up the ladder gives the user more certainty the person/website is who it says it is, but is more expensive and difficult to obtain for the person/website. Each step also costs more money for the CA to check, because there is more work to do. The "make it look green" and "fights crime" slogans were just the old marketing campaign, repeated endlessly as a more efficient sales pressure than the real explanation. While the point of EV was that it certified a binding to a (domain + business name) rather than just a domain with DV, it turned out that displaying the business name was also subject to abuse, and the security gain proved elusive. https://www.troyhunt.com/extended-validation-certificates-are-dead/ A traveling salesman for a cloud provider. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
On 05/12/2018 17:59, Viktor Dukhovni wrote: On Dec 5, 2018, at 4:49 AM, Jan Just Keijser wrote: The only reason to use OCSP I currently have is in Firefox: if you turn off "Query OCSP responder servers" in Firefox then EV certificates will no longer show up with their owner/domain name. IIRC Apple's Safari is ending support for EV, and some say that EV has failed, and are not sorry to see it go. This is very bad for security. So far the only real failures have been: 1. Some cloud provider(s) actively want to reduce all TLS security to the anonymous form provided by Let's encrypt, and are doing their worst to sabotage EV providing CAs. 2. As part of this campaign, those same cloud provider(s) take every opportunity to declare EV (and even OV) certificates as worthless and irrelevant. 3. At least one of those cloud provider(s) publishes a widely used "browser", in which they have preemptively removed support. Apple being tricked into removing support (contrary to their public hard stance on user security) is sad. Now the question is: does Firefox get OCSP "right" ;) ? Very likely yes. The Firefox TLS stack is maintained by experts. [ Also, FWIW, Firefox uses the "nss" library, not OpenSSL. ] However Firefox code also contains lots of idiotic usability bugs, even in the code that talks to the TLS stack. It is quite possible that the "OCSP must be on" rule is another bad usability hangover from the set of badly thought out UI changes made to initially promote EV certificates, just like the hiding of company names from non-EV certificates that actually contain them (so called OV certificates). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list
On 06/12/2018 11:48, Michael Ströder wrote: On 12/6/18 10:03 AM, Jakob Bohm via openssl-users wrote: On 05/12/2018 17:59, Viktor Dukhovni wrote: IIRC Apple's Safari is ending support for EV, and some say that EV has failed, and are not sorry to see it go. This is very bad for security. So far the only real failures have been: 1. Some cloud provider(s) actively want to reduce all TLS security to the anonymous form provided by Let's encrypt, and are doing their worst to sabotage EV providing CAs. Quoting from Peter Gutmann's "Engineering Security", section "EV Certificates: PKI-me-Harder" Indeed, cynics would say that this was exactly the problem that certificates and CAs were supposed to solve in the first place, and that “high-assurance” certificates are just a way of charging a second time for an existing service. I fully agree with the above and I'm also for removing this crap from the browser UI. Peter Gutman, for all his talents, dislikes PKI with a vengeance. EV is a standard for OV certificates done right. Which involves more thorough identity checks, stricter rules for the CAs to follow etc. The real point of EV certificates is to separate CAs that do a good job from those that do a more sloppy job, without completely distrusting the mediocre CA operations. Due to market forces, the good CAs also offer the weaker certificate types at a lower price to compete with the mediocre CAs that are aren't good/thorough enough to do the full job. The way EV certs are highlighted in Browsers (Green bar etc.) was a way to create market demand for the higher quality. They could be indicated in some other useful way of cause, but the distinguishment between "The CA did something to check the name and real world address in the certificate" (OV) versus "The CA checked the name and and real world address thoroughly in accordance with the higher quality standard" (EV) is still of some significance. If you look at that long list of CA roots preinstalled in a typical browser, only a minority are authorized, trusted and audited to issue to the higher EV standard. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What is the need for 0x00 byte prefix in pubkey and prime of a static DH key pair?
If the first byte has the high-bit set, then you have to put a leading-zero-byte so that it is not treated as a negative number. public-key: 00:a0:0d:41:8a:27:55:07:2a:01:dd:a7:e2:86:bb: ... prime: 00:a2:f4:9d:1c:3f:75:8f:3e:e3:c9:95:09:79:09: ... -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] OpenSSL Versioning and License
On 28/11/2018 23:42, Jonathan Larmour wrote: On 28/11/18 21:41, Daniel Kahn Gillmor wrote: On Wed 2018-11-28 19:54:34 +, Jonathan Larmour wrote: On 28/11/18 17:02, Matt Caswell wrote: Please see the following blog post about OpenSSL Versioning and License: https://www.openssl.org/blog/blog/2018/11/28/version/ :-( The Apache license is incompatible with GPLv2: https://www.apache.org/licenses/GPL-compatibility.html Those of us using GPLv2 code in products will no longer be able to use OpenSSL. For many of us, GPLv3 is not an option. The existing OpenSSL license is arguably incompatible with GPLv2 anyway, in some analyses: https://people.gnome.org/~markmc/openssl-and-the-gpl.html Yes I believe any GPLv2 users have been relying on a license exception. I'm not sure the license exception in the GPL software I'm using would be sufficient if calls to OpenSSL are made from the GPL'd code: "As a special exception, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other works to produce a work based on this file, this file does not by itself cause the resulting work to be covered by the GNU General Public License.[...]" If my own (non-GPL) code calls OpenSSL, that seems fine. But what if I have modified the GPL'd (with exception) code to call OpenSSL? That's not the exception used for OpenSSL using software, that looks more like the exception used when some software that should have been LGPL was annoyingly marked as GPL instead. The OpenSSL exceptions exist in very specific software packages and mention "OpenSSL" or "The OpenSSL license" by name. The problem (besides such an exception only applying if all the used GPL code has it) is that such an exception, depending on its wording, might not apply to an Apache-licensed OpenSSL, and it may be very hard to track down every GPL copyright holder and get them to sign off on a reworded exception that doesn't extend to other large Apache-licensed code bases. Another exception sometimes used is the "OS exception" (in the text of GPLv2 itself) applies only to an OS-bundled copy of OpenSSL, and only if the GPLv2 code is not bundled with the OS. For example if using the specific builds of OpenSSL distributed by Debian and RedHat, a GPLv2 program not packaged by those systems can use that specific version of OpenSSL. That said, I also would have liked something that is GPLv2-compatible in addition to GPLv3-compatible. Yes, that would have made things unambiguous. Jifl Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Creating PKCS#8 from pvk format
Hello,I am working on a small homework which requires convert pvk private key to PKCS#8 format. The code is based on OpenSSL 1.0.2. I can get pvk private key components (Public exponent, modulus, prime1, prime2, exponent1, exponent2, coefficient, private exponent) properly, and convert to a validRSA format (RSA_check_key()returns success). Now I need to convert the key in RSA format to EVP_PKEY, then to PKCS#8. I have tried the following functions, all of these functions return 0 (failure) without anyfurther debugging information/clues:EVP_PKEY_assign_RSA(pEvpkey, rsa);EVP_PKEY_set1_RSA(pEvpkey, rsa);PEM_write_bio_RSAPrivateKey (out, rsa, cipher, NULL, 0, NULL, NULL);PEM_write_bio_PKCS8PrivateKey(out, pEvpkey, 0, 0, 0, 0, 0); I did google searching, but have not figured out why the about functions failed (one posting mentions “export version” vs. domestic version??). So, I’d like to get some help, 1. hopefully, with more debug information. 2. suggestion: based on OpenSSL 1.0.2, what are the correct function-chain to change pvk private key to PKCS#5? Any suggestions, input are appreciated.Xuan -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Creating PKCS#8 from pvk format
Hi Wim,Thank you for your quick response.1. Yes. I called EVP_PKEY_new() before calling EVP_PKEY_assign_RSA(pEvpkey, rsa); 2. For your second quetion: no. I have not checked there is anything in the openssl error stack. I will check the openssl error stack. 3. (1). If it works, is EVP_PKEY_assign_RSA(pEvpkey, rsa) the correct function to call to get pEvpkey (EVP_PKEY) from a rsa private key?Is there any other alternative function to get pEvpkey (EVP_PKEY) from a rsa private key?(2), Once getting pEvpkey, can I call the following functions to get PKC#8 der format:(a). PKCS8_PRIV_KEY_INFO *p8 = EVP_PKEY2PKCS8(pEvpkey); (b). int der_len = i2d_PKCS8_PRIV_KEY_INFO(p8, ); Do you expect the above function call work? If not, what are the correct way to get pkcs#8 der from pvk format? Thank you On Tuesday, December 4, 2018, 7:40:19 PM EST, Wim Lewis wrote: On 4. des. 2018, at 4:00 e.h., zhongju li via openssl-users wrote: > Now I need to convert the key in RSA format to EVP_PKEY, then to PKCS#8. I > have tried the following functions, all of these functions return 0 (failure) > without any further debugging information/clues: > EVP_PKEY_assign_RSA(pEvpkey, rsa); Is it possible that pEvpkey or rsa is NULL? (You need to create a EVP_PKEY with EVP_PKEY_new() before putting a specific key into it.) Otherwise, have you checked whether there is anything in the openssl error stack (using ERR_get_error(), ERR_print_errors_fp(), or similar)? > I did google searching, but have not figured out why the about functions > failed (one posting mentions “export version” vs. domestic version??). There used to be different versions because of US export laws but I don't think that has been the case for many years. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Is there any standard way of getting the error name from an SSL error?
>For example, I want the string "SSL_R_TOO_MANY_WARN_ALERTS" for an error with that value, not just the "too many alerts" description. You're correct, it's not done. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 opaque structures
* BIGNUM structure also has been made opaque. How to refer the members of BIGNUM structure like bn->top ? You cannot. That is the definition of “opaque structure.” :) Why do you need to access “top” ? * And I don't see this API implementation ""lh_OPENSSL_CSTRING_new" in openssl-1.1.1 ? It is a static inline functions in include/openssl/safestack.h. Because it’s static-inline, it won’t show up unless it is actually used. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] AESCBC support in SSL
I think you missed the following:
Because CBC is the oldest block cipher mode in SSL and
TLS, the cipher suites using CBC don't include the
letters "CBC" in their names.They simply don't mention
a different mode (such as GCM or CCM).
For example ECDHE-RSA-AES128-SHA uses AES128 in CBC mode.
On 20/11/2018 10:54, ASHIQUE CK wrote:
Hi,
Any replys ?
On Mon, Nov 19, 2018 at 11:39 AM ASHIQUE CK <mailto:ckashique...@gmail.com>> wrote:
Also I use OpenSSL 1.1.0h.
On Mon, Nov 19, 2018 at 11:36 AM ASHIQUE CK
mailto:ckashique...@gmail.com>> wrote:
No, We use Ubuntu 16.04 OS
On Mon, Nov 19, 2018 at 11:34 AM Dmitry Belyavsky
mailto:beld...@gmail.com>> wrote:
Do you use any RedHat-based OS?
On Mon, Nov 19, 2018 at 8:54 AM ASHIQUE CK
mailto:ckashique...@gmail.com>>
wrote:
Is it the problem with that strings or TLS/SSL
version or any other ?
On Mon, Nov 19, 2018 at 11:12 AM ASHIQUE CK
mailto:ckashique...@gmail.com>> wrote:
Hi,
I had given all the cipher strings
for "SSL_CTX_set_cipher_list" which we get under
the command 'openssl ciphers' that includes CBC,
but any of them didnot worked. All of them showed
the error "error:141640B5:SSL
routines:tls_construct_client_hello:no ciphers
available". I have used TLSv1_2 or SSLv23.
Also I have tried setting these strings for
"SSLCipherSuite" at apache server configuration.
But it makes no change for choosing the server
default ciphersuit "ECDHE-RSA-AES256-GCM-SHA384".
Thanks
On Fri, Nov 16, 2018 at 9:15 PM Viktor Dukhovni
mailto:openssl-us...@dukhovni.org>> wrote:
> On Nov 16, 2018, at 7:45 AM, ASHIQUE CK
mailto:ckashique...@gmail.com>> wrote:
>
> Does SSL connection supports AESCBC?
Yes, but not under that name.
> I could not set AESCBC in
"SSL_CTX_set_cipher_list" at client side or in
"SSLCipherSuite" at apache server side.
For example (constrained also to RSA and ECDHE
to keep the list short):
$ openssl ciphers -v
'AES128+aRSA+kECDHE:!AESGCM'
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH
Au=RSA Enc=AES(128) Mac=SHA256
ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA
Enc=AES(128) Mac=SHA1
There isn't a cipherlist property that
specifically selects CBC, so to
get *only* CBC, you need to exclude AESGCM
(and perhaps also AESCCM).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 opaque structures
* I am unable to get the API to access bn->top value or any bn members in openssl 1.1.1 . Can you help me with the pointers to those APIs ? They do not exist. This is the first time someone has asked for them. You will need to open an issue on GitHub, and explain *why* you need access. * And I dont see "lh_OPENSSL_CSTRING_new " function in "include/openssl/safestack.h" ? Look for “DEFINE_SPECIAL_STACK_OF_CONST(OPENSSL_CSTRING” near the end of the file. Then trace through the macros. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] error message oddity
On 25/11/2018 22:30, Viktor Dukhovni wrote: On Nov 25, 2018, at 4:23 PM, Jeremy Harris wrote: That isn't the package name, it is text defined in openssl/opensslv.h That happens when "OPENSSL_FIPS" is defined: # define OPENSSL_VERSION_NUMBER 0x101000b0L # ifdef OPENSSL_FIPS # define OPENSSL_VERSION_TEXT "OpenSSL 1.1.0k-fips-dev xx XXX " # else # define OPENSSL_VERSION_TEXT"OpenSSL 1.1.0k-dev xx XXX " # endif Given no FIPS for 1.1.x, perhaps that "#ifdef" should be "#if 0". With 1.1.x the "Configure" arguments should not mention "fips". A better solution would be to have a separate part of the 1.1.0/1.1.1 headers error out hard (with #error) if attempting to build with OPENSSL_FIPS defined. This would preserve all the FIPS-related stuff (such as the above version naming code) for when a FIPS module for 1.1.x is provided, while leaving the blocking of accidental miscompilation in a clear location having no other effects. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Client CA list sending is also in TLS < 1.3 (RFC6066)
Hi, The ability of a TLS client to optionally send a list of trusted CAs to the TLS server is not new in TLS 1.3. In TLS 1.2 and older it was an extension "Trusted CA Indication" (3), defined in RFC6066 Chapter 6. So I would suggest that any OpenSSL API to control that feature in TLS 1.3 also affects the matching TLS < 1.3 functionality, and is separated from the APIs that control the TLS server sending a list of client certificate CAs to clients. This aspect was somehow missed in a recent discussion of this TLS 1.3 behavior (which I cannot find right now). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Error: does not have a number assigned
On 27/11/2018 11:50, EYAL INBAR wrote: Hello I try to add API,CMP_build_KUR_req, to crypto lib and get Error: CMP_build_KUR_req does not have a number assigned Any suggestion? This means you are compiling for a platform (probably Windows or OS/2) where names exported from DLLs are assigned unique numbers for fast lookup during application load. There is a source file in OpenSSL giving the assigned numbers. You will need to add numbers for you additional exports, and deal with the risk that a future OpenSSL release uses that number for something else. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] GSCheck fails for Windows 32build 'libeay32.dll' library
If GSCheck is just a tool to check if you remembered to build code with the buffer overflow checks that Microsoft C can insert, then you should just treat this as a warning that the tool doesn't know how to check code from other compilers (in this case the manual work of the OpenSSL team). On 28/11/2018 10:06, Vinay Kumar via openssl-users wrote: Hi All, The 32bit OpenSSL 1.1.0i library 'libeay32.dll' fails for binscope GSCheck on Windows. E:\libeay32.dll: error BA2022: libeay32.dll was compiled with the following modules for which a language could not be identified. Ensure these were compiled with debug information and run BinScope again: aes-586.obj aesni-x86.obj bf-586.obj bn-586.obj chacha-x86.obj cmll-x86.obj co-586.obj crypt586.obj des-586.obj ecp_nistz256-x86.obj ghash-x86.obj md5-586.obj poly1305-x86.obj rc4-586.obj rmd-586.obj sha1-586.obj sha256-586.obj sha512-586.obj vpaes-x86.obj wp-mmx.obj x86-gf2m.obj x86-mont.obj x86cpuid.obj Any idea on how to resolve this problem or is it expected behavior. NOTE: 1. Adding /GS flag and enabling debug mode did not resolve the problem. 2. The same works fine with 64bit Windows 'libeay32.dll' 3. For other OpenSSL library 'libssl32.dll', GSCheck passes for both 32bit and 64bit. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SNI callback
On Wed, Nov 28, 2018 at 08:48:10PM +, Jeremy Harris wrote: > OpenSSL 1.1.1 FIPS 11 Sep 2018 > RHEL 8.0 beta > > Using SSL_CTX_set_tlsext_servername_callback() > when the called routine returns SSL_TLSEXT_ERR_NOACK > I was expecting the handshake to fail. It carries > on; am I doing something wrong? NOACK is basically "pretend that there wasn't a callback here"; you should probably use SSL_TLSEXT_ERR_ALERT_FATAL to abort the connection if you want the handshake to fail. -Ben -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] OpenSSL Versioning and License
This was discussed around when OpenSSL first talked about the project. You might find it worth reading the various blog entries (and comment/responses) https://www.openssl.org/blog/blog/categories/license/ One thing to note is that cryptography can be a patent minefield, and the patent protections in the Apache license were important to the project at the time we decided which license to move to. Not everyone will be happy, and we knew that at the time. Overall, however, we felt that this was the best way to go. /r$, not a member of the project any more -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL - Session Resumption on an On-going Connection
>My question: How can I make LibOpenSSL-1.0.2g to send a ServerHello to the >Client on demand? The socket should not close, nor perform a renegotiation. You have to shutdown and restart the TLS layer. You cannot send arbitrary ServerHello messages, it’s a protocol violation. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Client CA list sending is also in TLS < 1.3 (RFC6066)
On 26/11/2018 20:04, Viktor Dukhovni wrote: On Nov 26, 2018, at 11:33 AM, Jakob Bohm via openssl-users wrote: In TLS 1.2 and older it was an extension "Trusted CA Indication" (3), defined in RFC6066 Chapter 6. So I would suggest that any OpenSSL API to control that feature in TLS 1.3 also affects the matching TLS < 1.3 functionality, and is separated from the APIs that control the TLS server sending a list of client certificate CAs to clients. This aspect was somehow missed in a recent discussion of this TLS 1.3 behavior (which I cannot find right now). Thanks for the update. I guess OpenSSL never implemented RFC6066. I am not sure that support this in TLS 1.2 is worth adding, but you have a valid of principle. If it were added, it should use the same API that supports the equivalent feature in TLS 1.3 in OpenSSL 1.1.1a. Just to clarify: RFC6066 is the main RFC for basic TLS extensions, with chapters defining such things as SNI, and OCSP stapling. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
I would expect that smartphone clients might want to prioritize CHACHA over AES, but I don't think Node cares about that environment. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL_CTX_set_cert_verify_callback and certificate access
On 10/01/2019 18:00, Michael Wojcik wrote: From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Jordan Brown Sent: Thursday, January 10, 2019 11:15 On 1/9/2019 6:54 PM, Corey Minyard wrote: 2. Set the userid in the certificate and use client authentication to authenticate the user logging in. Set the username in the CN field of the certificate so it can't be changed, extract that and set the CA before verification. This is what I'm currently trying to do, and I keep running into roadblocks. Why do you think you need to set the CA? Agreed. That's an odd requirement. Then you look at their subject name to derive the user ID (probably from its CN). That's one logical option, but some systems (e.g. IBM zOS) instead maintain a database mapping client certificates to system user IDs. That has the advantage of not imposing any particular requirement on the client certificate's subject name format, with the disadvantage of additional administration. (For HTTPS, there's a provision for "automatic registration" where an unrecognized but valid and trusted client certificate will trigger HTTP Basic Authentication, and if those credentials are verified by the OS, the certificate is added to the database.) The database may index certificates by subject DN (for ease of administration, e.g. when certificates are renewed) or by fingerprint (as a defense against impersonation if a CA is compromised). If you want to be really paranoid - if you believe that Verisign can vouch for John and Comodo can vouch for Sam, but not vice versa, factor the issuer name into the process. Right. For the original "set the CA" plan to work, you would need to already have some association between client certificates and CAs, so you can simply check that a validated client certificate was issued by the expected CA. But again this would be an unusual requirement; and even if it exists, the contemporary standard mechanism for guarding against rogue or compromised CAs is Certificate Transparency. Checking CT logs seems like overkill in this case, and it would arguably be more useful to implement revocation checks and other defenses first; but if restricting certificates by issuer is important for some reason, CT might be a better approach than inventing your own mechanism. CT does nothing of the sort, it just provides a means to ensure all certificates are potentially subject to 3rd party audits. And CT cannot be legally used for user certificates anyway because CT publishes unredacted certificate content to the world. One really should be careful with security ideas from a company whose main source of income is to spy on the world population for profit. Regarding Corey's original note: SSL/TLS does not have a "username" concept because it would be redundant or inconsistent. A certificate is a peer identifier; it takes the place of a username. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Session params output fails via cron
On 04/01/2019 22:04, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Jordan Brown
Sent: Friday, January 04, 2019 13:16
If you want to, what you want is something like:
int fd;
do {
fd = open("/dev/null", O_RDWR);
} while (fd < 3);
close(fd);
(That's strictly not quite right, since it leaves 0 open writable and 1 and 2
open readable,
but that's pretty harmless.)
Behavior is unfortunate if open fails, e.g. because the NFILES limit is reached, or because
/dev/null is inaccessible (e.g. due to a poorly-configured chroot). You'd be better off with
(fd >= 0 && fd < 3).
Since source bytes are cheap, though, and there are at most three opens to be
done, I'd just do it explicitly for the three stdio descriptors. That would
also make the intention clear. (Yes, the intention of your version is clear to
old UNIX hands. It might not be to other people.)
I'm ignoring portability considerations, since I personally don't think this
would be a great thing to implement in the apps, so I'm not going to be
submitting a PR for it.
A chroot with no other reason to open /dev/null should not contain that
file name, even on unix-like platforms (least privilege chroot design).
Please refer to my previous post about the many other reasons why
opening /dev/null has a high risk of failure.
Stepping back, it is worth investigating if:
- Running TLS1.3 s_client with -ignoreeof and no stdin actually fails
earlier than with stdin == /dev/null
- If this is triggered by a code bug.
P.S.
On some Debian systems, cron runs scripts with stdout and stderr piped
(directly or indirectly) to a mail program that times out if a cron job
runs for a long time.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Compiling FIPS-cable OpenSSL on Windows Server 2012R2
I perused the list archives for all of 2018 and did not see anything current relating to this problem, so if this is a question that has been asked & answered, please feel free to point me at the relevant location to read about what I'm doing incorrectly. =) I'm not at all familiar with Windows & compiling Open Source projects, but I am having no trouble on Linux with OpenSSL + FIPS. On Windows, with Visual Studio 2017 (Community Edition), I am able to compile the FIPS 2.0.16 module and OpenSSL 1.0.2q (NO FIPS) without issue. When I try to compile OpenSSL with the FIPS canister, per the User Guide instructions, I end up with the following error. cl /Fotmp32dll\o_fips.obj -Iinc32 -Itmp32dll /MD /Ox -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DUNICODE -D_UNICODE -D_CRT_SECURE_NO_DEPRECATE -Ic:\..\openssl-fips/ include -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO _SSL2 -DOPENSSL_NO_KRB5 -DOPENSSL_FIPS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_WEAK_SSL_ CIPHERS -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUIL D_SHLIBCRYPTO -c .\crypto\o_fips.c o_fips.c .\crypto\o_fips.c(61): fatal error C1083: Cannot open include file: 'openssl/fip s.h': No such file or directory NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017 \Community\VC\Tools\MSVC\14.16.27023\bin\HostX86\x86\cl.EXE"' : return code '0x2 ' Stop. I am doing the following to compile FIPS: cd c:\path\to\fips-source ms\do_fips no-asm I am doing the following to compile OpenSSL+FIPS (Strawberry Perl installed): cd c:\path\to\openssl-source nmake -f ms\ntdll.mak clean nmake -f ms\nt.mak clean perl Configure VC-WIN64A fips no-asm --with-fipsdir=c:\path\to\fips-source ms\do_win64a no-asm nmake -f ms\ntdll.mak I feel like I'm missing something fundamental here and I know the User Guide says to install the FIPS files in a protected area. However, as I'm just building the source on this device, shouldn't I be able to to do the above and have it work? Any help would be greatly appreciated. Thanks, Chris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] RNG behavior by default
Small corrections below: On 07/01/2019 19:31, Steffen Nurpmeso wrote: ... |> That is really bad. Of course you had to do it like this, and you |> surely have looked around to see what servers and other software |> which use OpenSSL do with the PRNG after forking (i.e., whether |> they reiterate the [RAND_file_name(),] RAND_load_file(), |> [:[RAND_add(),] RAND_status()], [RAND_write_file()] dance as |> documented, or not). | |I really don't understand your frustration: the new PRNG was designed |to relieve the application from the burden of seeding. It is easier to use, |not more complicated: No need to call RAND_add(), RAND_seed(), |RAND_load_file() and all this stuff. Just make sure the os entropy sources |are available and then simply use RAND_bytes(). But don't expect it to |succeed always. And may i ask, what to do if it fails? Try it in a loop a finite number of times, assuming it over-and-over detects it is in an error state and tries to reseed unless that succeeds, and bail if still without success thereafter? Talking about the only program in the public that i represent: i will not abort that one just because a PRNG fails to produce some bytes that this program uses for the purpose of, well, having some (pseudo but) random bytes; because: this is _completely_ disproportionate to the use cases of those random numbers. I guess the same could be said about UUIDS generated via PRNGs instead of how the standard defines them, etc. etc. Please do not say "use random(3) or rand(3)" now, please. So what to do? "Just failing" is precisely to allow you (and others) to do something sensible without the random bytes, such as using something less secure, or doing a polite error reporting to the user. |> I think i will move away from RAND_ then, nonetheless, and at |> least for the things i have control of. | |I don't think this is a good idea. In the case when there is no suitable \ |entropy |source, the OpenSSL RNG will fail to generate random bytes, indeed. |But how do you expect your application to seed the RNG properly in this |case? What is your application's entropy source? If you have one, which Yes, that is the problem. We do have several possibilities for VAL_RANDOM. Some of them only seed our builtin ARC4 implementation, which until now exposes the internal buffer as such (sufficient for our purpose yet). Examples of this are /dev/urandom, Linux getrandom as system call or library call, aehh... If that seeding fails, we create a completely unscientific homebrew seed via CLOCK_REALTIME or gettimeofday(2), whatever is available, wildly XORing through the buffer, further randomizing those weakly through the well-known algorithm from "Random number generators: good ones are hard to find", Park and Miller, Communications of the ACM, vol. 31, no. 10, October 1988, p. 1195 (a_aux_rand_weak()). This is the code: Note that since that ancient article, ARC4 was not only invented, but also found too insecure for modern use. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Compiling FIPS-cable OpenSSL on Windows Server 2012R2
> > On Jan 7, 2019, at 09:20, Chris Fernando via openssl-users > wrote: > > I perused the list archives for all of 2018 and did not see anything current > relating to this problem, so if this is a question that has been asked & > answered, please feel free to point me at the relevant location to read about > what I'm doing incorrectly. =) > > I'm not at all familiar with Windows & compiling Open Source projects, but I > am having no trouble on Linux with OpenSSL + FIPS. On Windows, with Visual > Studio 2017 (Community Edition), I am able to compile the FIPS 2.0.16 module > and OpenSSL 1.0.2q (NO FIPS) without issue. > > [snip] > > > I am doing the following to compile FIPS: > cd c:\path\to\fips-source > ms\do_fips no-asm > > I am doing the following to compile OpenSSL+FIPS (Strawberry Perl installed): > cd c:\path\to\openssl-source > nmake -f ms\ntdll.mak clean > nmake -f ms\nt.mak clean > perl Configure VC-WIN64A fips no-asm --with-fipsdir=c:\path\to\fips-source > ms\do_win64a no-asm > nmake -f ms\ntdll.mak > > [snip] Well, I managed to get the compile to move a bit further by copying "inc32" to "include", "util" to "bin", and "out32dll" to "lib" in the FIPS source directory, that I was including in --with-fipsdir= . However, now I am getting the following error during the OpenSSL build process. cl /Fotmp32dll\fips_premain_dso.obj -DFINGERPRINT_PREMAIN_DSO_LOAD -Iinc 32 -Itmp32dll /MD /Ox -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -Gy -nologo -DOPEN SSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DUNICODE -D_UNICODE -D_CRT_S ECURE_NO_DEPRECATE -IC:\Users\cfernando\Downloads\ossl\ossl\openssl-fips/include -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_SSL2 - DOPENSSL_NO_KRB5 -DOPENSSL_FIPS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_WEAK_SSL_CIPHERS -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/app -c C:\Users\cfernando\Downloads\ ossl\ossl\openssl-fips\lib\fips_premain.c fips_premain.c ml /c ms\uptable.asm Microsoft (R) Macro Assembler Version 14.16.27025.1 Copyright (C) Microsoft Corporation. All rights reserved. Assembling: ms\uptable.asm ms\uptable.asm(9) : error A2006:undefined symbol : rsp ms\uptable.asm(10) : error A2006:undefined symbol : rsp ms\uptable.asm(11) : error A2006:undefined symbol : rsp ms\uptable.asm(12) : error A2006:undefined symbol : rsp ms\uptable.asm(13) : error A2006:undefined symbol : rcx ms\uptable.asm(14) : error A2006:undefined symbol : rdx ms\uptable.asm(16) : error A2006:undefined symbol : rcx ms\uptable.asm(17) : error A2006:undefined symbol : rdx ms\uptable.asm(18) : error A2006:undefined symbol : r8 ms\uptable.asm(19) : error A2006:undefined symbol : r9 ms\uptable.asm(20) : error A2006:undefined symbol : rax ms\uptable.asm(21) : error A2006:undefined symbol : rsp ms\uptable.asm(22) : error A2006:undefined symbol : rax ms\uptable.asm(29) : error A2006:undefined symbol : rsp ms\uptable.asm(30) : error A2006:undefined symbol : rsp ms\uptable.asm(31) : error A2006:undefined symbol : rsp ms\uptable.asm(32) : error A2006:undefined symbol : rsp ms\uptable.asm(33) : error A2006:undefined symbol : rcx ms\uptable.asm(34) : error A2006:undefined symbol : rdx ms\uptable.asm(36) : error A2006:undefined symbol : rcx ms\uptable.asm(37) : error A2006:undefined symbol : rdx ms\uptable.asm(38) : error A2006:undefined symbol : r8 ms\uptable.asm(39) : error A2006:undefined symbol : r9 ms\uptable.asm(40) : error A2006:undefined symbol : rax ms\uptable.asm(41) : error A2006:undefined symbol : rsp ms\uptable.asm(42) : error A2006:undefined symbol : rax ms\uptable.asm(49) : error A2006:undefined symbol : rsp ms\uptable.asm(50) : error A2006:undefined symbol : rsp ms\uptable.asm(51) : error A2006:undefined symbol : rsp ms\uptable.asm(52) : error A2006:undefined symbol : rsp ms\uptable.asm(53) : error A2006:undefined symbol : rcx ms\uptable.asm(54) : error A2006:undefined symbol : rdx ms\uptable.asm(56) : error A2006:undefined symbol : rcx ms\uptable.asm(57) : error A2006:undefined symbol : rdx ms\uptable.asm(58) : error A2006:undefined symbol : r8 ms\uptable.asm(59) : error A2006:undefined symbol : r9 ms\uptable.asm(60) : error A2006:undefined symbol : rax ms\uptable.asm(61) : error A2006:undefined symbol : rsp ms\uptable.asm(62) : error A2006:undefined symbol : rax ms\uptable.asm(69) : error A2006:undefined symbol : rsp ms\uptable.asm(70) : error A2006:undefined symbol : rsp ms\uptable.asm(71) : error A2006:undefined symbol : rsp ms\uptable.asm(72) : error A2006:undefined symbol : rsp ms\uptable.asm(73) : error A2006:undefined symbol : rcx ms\uptable.asm(74) : error A2006:undefined symbol : rdx ms\uptable.asm(76) : error A2006:undefined symbol : rcx ms\uptable.asm(77) : error A2006:undefined symbol : rdx ms\uptable.asm(78) : error A2006:undefined symbol : r8 ms\uptable.asm(79) : er
Re: [openssl-users] Session params output fails via cron
On 07/01/2019 22:26, Jordan Brown wrote: [ Off topic for OpenSSL... ] On 1/7/2019 8:06 AM, Jakob Bohm via openssl-users wrote: A chroot with no other reason to open /dev/null should not contain that file name, even on unix-like platforms (least privilege chroot design). There's always a first reason :-) But also: /dev/null is part of the definition of UNIX <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap10.html#tag_10_01>. Programs have every right to expect that it will be there. Yes, you can build a chroot environment that doesn't include it... but then you can't complain when programs don't work in your environment. You can also build an environment that doesn't include system libraries, and there are reasons to do so, but few programs will work in it. Looking at Solaris, about 15% of the programs in /usr/bin and 5% of the libraries in /usr/lib have a reference to /dev/null. The whole point of a chroot jail is to deny a program access to any and all parts of Unix (and the local flavor) it won't need. For example, most chroot jails remove /bin/ls, with ftp servers as the major exception. Thus /dev/null being part of UNIX/POSIX doesn't say anything about its availability in chroot jails. Nor does it say anything about its availability on non-unix platforms, many of which are explicitly supported by the OpenSSL libraries. For many programs, it is standard to chroot to a directory with nothing or almost nothing after loading configuration files, code, certificates etc. /var/empty and /var/www are common examples. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] RNG behavior by default
On 07/01/2019 22:31, Steffen Nurpmeso wrote: > Good evening. > > Jakob Bohm via openssl-users wrote in <95bceb59-b299-015a-f9c2-e2487a699\ > 8...@wisemo.com>: > |Small corrections below: > | ... Note that I do not represent the project at all, I am just another user trying to help you. As such, I cannot really respond to your criticism of other project aspects, some of which I myself don't like either, while others are obvious to me as someone who has more or less followed along since this was a two-man Australian project. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Session params output fails via cron
On 03/01/2019 12:52, Neil Craig wrote: Thanks for the quick reply Matt. I tried -ign_eof but it had no effect, sadly. If anyone has any further suggestions, I¹d appreciate it very much as this is in aid of our automated released testing for TLS1.3 on our production traffic management service. Cheers Neil Craig Lead Technical Architect | Online Technology Group Broadcast Centre, London W12 7TQ | BC4 A3 Twitter: https://twitter.com/tdp_org On 03/01/2019, 11:02, "openssl-users on behalf of Matt Caswell" wrote: On 03/01/2019 10:31, Neil Craig wrote: Hi all Does anyone know why openssl (silently) fails to write session data to a file when run from cron? (It works fine running manually) via e.g.: /path/to/openssl s_client -connect :443 -servername -tls1_3 sess_out Running the same command but with tls1_2 works fine from cron. This feels like it might be a bug? Or am I missing something? There¹s nothing obvious in the output that suggests failure. Any help would be much appreciated, happy to provide more info and/or do more testing. TLSv1.3 sessions work differently to TLSv1.2 sessions. Significantly a TLSv1.2 session is established during the handshake. In TLSv1.3 the handshake completes first. At that point data can be exchanged. At some later point (usually immediately after the handshake has completed) the server may send to the client new session ticket messages to create a session for later resumption. When s_client is run non-interactively it will connect to the server and complete the handshake. It will then read any data from stdin and send it to the server. It will keep doing this until it hits EOF from stdin and then close the connection. My guess is that s_client is closing the connection before the server has had a chance to send its new session tickets. You might want to experiment with the -ign_eof option to s_client. This will keep s_client running even after having hit EOF from stdin. Maybe cron jobs are run without a valid stdin handle (rather than a readable handle at EOF), in which case explicitly adding "https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Session params output fails via cron
Two of the more common causes of cron failure are - Environment variable missing or has different value (PATH etc) - File permissions are different if running under root vs normal interactive user. Hope that helps. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] tls1_change_cipher_state
On 02/01/2019 11:18, Dennis Clarke wrote: On 1/2/19 5:14 AM, Jakob Bohm via openssl-users wrote: On 02/01/2019 10:41, Matt Caswell wrote: On 27/12/2018 08:37, Dmitry Belyavsky wrote: Hello, Am I right supposing that local variables tmp1, tmp2, iv1, and iv2 are unused in this function? Looks that way. They should be removed. By the way, why aren't any of your test compilers configured to warn about unused local variables? It's a common feature in many compilers and thus a free consistency check that can catch typos. Traditionally ( past four decades ) that was a feature provided by something like 'lint' but I have not seen a lint picker lately other than in the Oracle Studio compiler tools and it certainly isn't open source in any way. Works very well however. Most traditional lint features have migrated into the compilers (as warnings). In this case gcc -Wunused enables a number of such warnings. Microsoft Visual C includes an advanced but flawed supplemental linter in the form of the PREfast (code analysis) feature, which tries to do semantic consistency checks for things like buffer sizes and semaphore use. This is closed source however. By the way, I wonder if there is a way to tell gcc or clang that OPENSSL_cleanse doesn't count as usage, without triggering other warnings (such as not using the value written by by OPENSSL_cleanse). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] tls1_change_cipher_state
On 02/01/2019 10:41, Matt Caswell wrote: On 27/12/2018 08:37, Dmitry Belyavsky wrote: Hello, Am I right supposing that local variables tmp1, tmp2, iv1, and iv2 are unused in this function? Looks that way. They should be removed. By the way, why aren't any of your test compilers configured to warn about unused local variables? It's a common feature in many compilers and thus a free consistency check that can catch typos. Of cause doing so requires establishing a coding standard for how to silence such warnings where a local variable is used only in conditionally compiled code. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Session params output fails via cron
Jakob - you’re a star! Thanks so much, your suggestion works. So I added https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Session params output fails via cron
On 04/01/2019 18:15, Salz, Rich wrote: Jakob - you’re a star! Thanks so much, your suggestion works. So I added Maybe open an issue to catch this. Seems like the apps could check and redirect to /dev/null if the FD isn't valid. Perhaps it is simpler to just accept invalid stdin if -ignoreeof is set. In particular, this avoids dealing with OS specific names of /dev/null, as well as chroot jails without that character device. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL_CTX_set_cert_verify_callback and certificate access
On 10/01/2019 19:55, Corey Minyard wrote: On 1/10/19 11:00 AM, Michael Wojcik wrote: From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Jordan Brown Sent: Thursday, January 10, 2019 11:15 On 1/9/2019 6:54 PM, Corey Minyard wrote: 2. Set the userid in the certificate and use client authentication to authenticate the user logging in. Set the username in the CN field of the certificate so it can't be changed, extract that and set the CA before verification. This is what I'm currently trying to do, and I keep running into roadblocks. Why do you think you need to set the CA? Agreed. That's an odd requirement. Thanks for the responses. It is unusual, perhaps, but I'm trying to implement something like ssh does. I can't expect users of ser2net to obtain certificates from a real certificate authority, that's too high a barrier for entry. I want them to be able to generate a key pair, put the public key on the server in their account, and authenticate against that. It's a balance of getting reasonable security that people will actually use. A simpler solution is to report "Any client CA accepted", then compare the returned certificate fingerprint (strong hash of DER-encoded end cert) against a user database, listing the user name for each cert. Validation then only checks if the certificate is revoked or technically invalid (expired, claims to be signed by a CA that didn't, syntactically invalid, wrong Extended-Key-Usage etc.). But signed by a completely unknown CA, or self-signed is A-OK as long as the end cert is listed as belonging to that user (similar to an SSH public key). By the way, I do think ssh can be made to work by handing the SSH library the actual serial port handles once the user has been authenticated. Some SSH libraries may even be able to do things like BREAK via standard SSH mechanisms. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 manuals
Great idea; https://github.com/openssl/web/issues/101 On 12/28/18, 12:39 AM, "Jakob Bohm via openssl-users" wrote: Consider at least including the one-line manpage summaries on the index pages (the ones displayed by the apropos command on POSIX systems). -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] License change still scheduled for 1.1.1 ?
1.1.1 release still has the legacy license. Should we still expect a license change? Thank you. ‐‐‐ Original Message ‐‐‐ On Monday, June 25, 2018 5:20 PM, Salz, Rich wrote: > - Do you still plan to switch to Apache license for the final 1.1.1 release? > > That is still our goal, as stated.-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] QNX 6.5 OpenSSL Build
Hi,Am trying to build the openssl source for QNX 6.5/6.6 OS. I have tried to build after the instructions given in internet. 1. QNX 6.6 build environment variable is set. 2. Executed below command. sh-3.1$ ./Configure QNX6 shared --prefix=./qnx660/release --openssldir=./qnx660/release 3. make depend exectuted. Got compilation error. ../../util/domd ../.. -MD gcc -- -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE -DOPENSSL_NO_LIBUNBOUND -DOPENSSL_NO_MD2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_RFC3779 -DOPENSSL_NO_SCTP -DOPENSSL_NO_SSL_TRACE -DOPENSSL_NO_SSL2 -DOPENSSL_NO_STORE -DOPENSSL_NO_UNIT_TEST -DOPENSSL_NO_WEAK_SSL_CIPHERS -- dso_dl.c dso_dlfcn.c dso_err.c dso_lib.c dso_null.c dso_openssl.c dso_win32.c dso_vms.c dso_beos.cdso_dlfcn.c:84:12: fatal error: dlfcn.h: No such file or directory # include Also when I executed make all from command line. Seems like nothing has been built. sh-3.1$ makesh-3.1$ make allsh-3.1$ Could anyone help me out to build openssl for qnx 6.5 os. Thanks,Murugaiyan -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working
Much work for little gain and purpose. You can mix drafts, but mixing the draft and the official version is hard, there's too many semantic changes (e.g., around fallback vs no-fallback-protection). -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Limit the number of AES-GCM keys allowed in TLS
This is factually incorrect; the TLS values are lower than the FIPS values, for example. And also, what “everyone in the know” has always stated isn’t really true any more. It would be nice to keep politics out of this list. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working
>My point was about the likelihood of last-draft browsers lingering on in the real world for some time (like 1 to 3 years) after the TLS1.3-final browser versions ship. I do not think this is a concern. Chrome and FF auto-update and get almost full coverage within a month or two, for example. Edge hasn't shipped TLS 1.3 yet. Safari encourages auto-update. That's most of the browser market. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working
On Wed, Sep 12, 2018 at 03:50:17PM +0200, Klaus Keppler wrote: > Hi, > > when I create a TLS-1.3-only "web" server with s_server (from OpenSSL > 1.1.1-release), Firefox/Chrome can't access it. > According to all docs I've read so far, the TLS 1.3 implementations both > from Firefox (62.x) and from Chrome (69.x) should be compatible so far. You need to check that the browser is implementing the final RFC 8446 version and not an earlier draft version -- two are incompatible by design (and OpenSSL 1.1.1 implements the final RFC 8446 version). IIUC, only Firefox nightly as of approximately today will support the final RFC 8446 version; I haven't looked into Chrome yet. -Ben -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 and FreeBSD 11.2
On Tue, Sep 11, 2018 at 10:48:40AM -0600, The Doctor wrote: > On Tue, Sep 11, 2018 at 09:33:36AM -0600, The Doctor wrote: > > Looks likes I found a first bug > > > > ../test/recipes/70-test_comp.t . > > Proxy started on port [::1]:10789 > > Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server > > -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept > > [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 > > -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256 > > engine "ossltest" set. > > Using default temp DH parameters > > ACCEPT [::1]:39577 > > Server responds on [::1]:39577 > > panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg stack: > > base=805d16098, sp=805d160e8, hwm=805d160d0 > > > > Using perl 5.28.1 The test suite needs some modules not included in the core perl port/package. You should probably list out what p5-* you have installed. Also, do you have any IPv6 addresses configured? -Ben -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 and FreeBSD 11.2
On Tue, Sep 11, 2018 at 03:04:06PM -0600, The Doctor wrote: > On Tue, Sep 11, 2018 at 02:57:09PM -0500, Benjamin Kaduk via openssl-users > wrote: > > On Tue, Sep 11, 2018 at 10:48:40AM -0600, The Doctor wrote: > > > On Tue, Sep 11, 2018 at 09:33:36AM -0600, The Doctor wrote: > > > > Looks likes I found a first bug > > > > > > > > ../test/recipes/70-test_comp.t . > > > > Proxy started on port [::1]:10789 > > > > Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server > > > > -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept > > > > [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem > > > > -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256 > > > > engine "ossltest" set. > > > > Using default temp DH parameters > > > > ACCEPT [::1]:39577 > > > > Server responds on [::1]:39577 > > > > panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg > > > > stack: base=805d16098, sp=805d160e8, hwm=805d160d0 > > > > > > > > > > Using perl 5.28.1 > > > > The test suite needs some modules not included in the core perl > > port/package. > > You should probably list out what p5-* you have installed. > > > p5-Archive-Zip-1.63Create, manipulate, read, and write Zip > archive files > p5-Authen-NTLM-1.09_1 Perl5 NTLM authentication module > p5-Authen-PAM-0.16_2 Perl interface to the PAM library > p5-Authen-SASL-2.16_1 Perl5 module for SASL authentication > p5-Business-ISBN-3.004 Work with International Standard Book Numbers > p5-Business-ISBN-Data-20140910.003 Data pack for Business::ISBN > p5-CGI-4.40Handle Common Gateway Interface requests and > responses > p5-Class-Inspector-1.32Provides information about classes > p5-Convert-ASN1-0.27_2 Perl5 module to encode and decode ASN.1 data > structures > p5-Convert-BinHex-1.125Perl module to extract data from Macintosh > BinHex files > p5-Convert-TNEF-0.18_1 Perl module to read TNEF files > p5-Crypt-OpenSSL-Bignum-0.09 OpenSSL's multiprecision integer arithmetic > p5-Crypt-OpenSSL-Guess-0.11Guess OpenSSL include path > p5-Crypt-OpenSSL-RSA-0.30_1Perl5 module to RSA encode and decode strings > using OpenSSL > p5-Crypt-OpenSSL-Random-0.15 Perl5 interface to the OpenSSL pseudo-random > number generator > p5-Crypt-SSLeay-0.72_3 Perl5 interface to allow p5-libwww LWP to make > https connections > p5-DBD-SQLite-1.58 Provides access to SQLite3 databases through > the DBI > p5-DBD-mysql-4.046 MySQL driver for the Perl5 Database Interface > (DBI) > p5-DBI-1.641 Perl5 Database Interface, required for DBD::* > modules > p5-Data-Dump-1.23_1Pretty printing of data structures > p5-Date-EzDate-1.16Date and time manipulation made easy > p5-Devel-CheckLib-1.13 Check that a library is available > p5-Digest-BubbleBabble-0.02_1 Perl5 interface to a fingerprint in "bubble > babble" format > p5-Digest-HMAC-1.03_1 Perl5 interface to HMAC Message-Digest > Algorithms > p5-Digest-SHA1-2.13_1 Perl interface to the SHA-1 Algorithm > p5-Encode-Detect-1.01_1Encode::Encoding subclass that detects the > encoding of data > p5-Encode-Locale-1.05 Determine the locale encoding > p5-Error-0.17026 Error/exception handling in object-oriented > programming style > p5-ExtUtils-Depends-0.405 Easily build XS extensions that depend on XS > extensions > p5-ExtUtils-PkgConfig-1.16 Simplistic interface to pkg-config > p5-File-Listing-6.04_1 Parse directory listings > p5-File-ShareDir-1.116 Locate per-dist and per-module shared files > p5-File-ShareDir-Install-0.13 Install read-only data files from a > distribution > p5-Filesys-Df-0.92_1 Perl extension for filesystem space > p5-Filter-1.59 Number of source filters for perl5 programs > p5-GD-2.68 Perl5 interface to Gd Graphics Library version2 > p5-GD-Barcode-1.15_6 GD::Barcode - Create barcode image with GD > p5-GSSAPI-0.28_1 Perl extension providing access to the > GSSAPIv2 library > p5-Geo-IP-1.51 Gets country name by IP or hostname > p5-Geography-Countries-2009041301_1 Handle ISO-3166 country codes > p5-Glib2-1.327 This module provides access to Glib and > GObject libraries > p5-HTML-Parser-3.72Perl5 module for parsing HTML document
Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working
On Thu, Sep 13, 2018 at 08:13:41PM +0200, Jakob Bohm wrote: > On 13/09/2018 09:57, Klaus Keppler wrote: > >Hi, > > > >thank you for all your responses. > > > >I've just tested with Firefox Nightly 64.0a1, and both s_server and our > >own app (using OpenSSL 1.1.1-release) are working fine. > > > >The Firefox website is quite confusing: > > > >>Firefox 61 is already shipping draft-28, which is essentially the same as > >>the final published version (just with a different version number). > >(https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/) > > > >This is quite confusing, as it sounds better than it actually is. > >(so I've just learned that draft-28 is obviously incompatible with RFC8446) > > > >So thank you for your input, will now continue with OpenSSL 1.1.1. > >The rest will be only a matter of time. :D > > > >Best regards > > > >-Klaus > Would it be reasonable for 1.1.1a to add a transitional "bugs" bit (to be > removed again in a few years) to accept the draft version number of final > TLS 1.3, if the protocols are otherwise identical? > > This would be similar to the (now historic) bits for known bugs in other > popular clients. It also seems to be what Facebook has done for their > own servers (according to other posts in this discussion). > > Or would it be unproblematic from a real world perspective to just keep > TLS 1.3 non-functional for draft-28 browsers? It would be unproblematic. Such browsers will use TLS 1.2 just fine, and are going to be auto-updating to a version capable of official TLS 1.3 very soon anyway. -Ben -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] decrypt error
Since this seems to be a certificate issue, would it be possible to make the server log all the certificate checking steps and errors with the failing certificates. One obvious test would be to try connecting to the "openssl s_server" utility with a similar configuration and lots of debug options. Another would be to install all the debug symbols and running haproxy under a debugger with strategically set breakpoints to look at the execution stack when errors are reported or validation occurs. On 24/01/2019 16:55, Scharfenberg, Carsten wrote: Yes, it works if I deactivate client auth. Concerning the cipher: I use one specific cipher on server and on client side. This is the only cipher supported by the actual hardware client. Concerning the sigalg: I've had big trouble with this because due to bug in the client I need to restrict the sigalgs offered by the server. This is not possible with haproxy. But it is possible with openssl.cnf since version 1.1.1. This is why I've installed haproxy and openssl from Debian testing. So I'm very confident about the cipher suite and the signature algorithm. I've just created a new certificate hierarchy. Et voila: it works. So obviously this issue is certificate-related. Still I have to figure out what is wrong with the old certificates because I cannot replace them in the productive environment. My next step will be to create new hierarchy again that matches the original hierarchy as close as possible (including constraints and extensions). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: PKCS#7/CMS verify reports bad signature
On 02/04/2019 10:44, Matt Caswell wrote: On 01/04/2019 22:23, Steffen wrote: Hello, I believe that I have narrowed the problem down to one specific version of OpenSSL. Version 1.1.0b works as expected while OpenSSL 1.1.0c does not. Using the cert/data files you provided me off-list (thanks), I was able to confirm the above and narrow it down further to the following commit: commit b71079a375116a8a52ed493afcd8f69cb08c195a Author: David Benjamin Date: Sat Aug 20 13:35:17 2016 -0400 Implement RSASSA-PKCS1-v1_5 as specified. RFC 3447, section 8.2.2, steps 3 and 4 states that verifiers must encode the DigestInfo struct and then compare the result against the public key operation result. This implies that one and only one encoding is legal. OpenSSL instead parses with crypto/asn1, then checks that the encoding round-trips, and allows some variations for the parameter. Sufficient laxness in this area can allow signature forgeries, as described in https://www.imperialviolet.org/2014/09/26/pkcs1.html Although there aren't known attacks against OpenSSL's current scheme, this change makes OpenSSL implement the algorithm as specified. This avoids the uncertainty and, more importantly, helps grow a healthy ecosystem. Laxness beyond the spec, particularly in implementations which enjoy wide use, risks harm to the ecosystem for all. A signature producer which only tests against OpenSSL may not notice bugs and accidentally become widely deployed. Thus implementations have a responsibility to honor the specification as tightly as is practical. In some cases, the damage is permanent and the spec deviation and security risk becomes a tax all implementors must forever pay, but not here. Both BoringSSL and Go successfully implemented and deployed RSASSA-PKCS1-v1_5 as specified since their respective beginnings, so this change should be compatible enough to pin down in future OpenSSL releases. See also https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 As a bonus, by not having to deal with sign/verify differences, this version is also somewhat clearer. It also more consistently enforces digest lengths in the verify_recover codepath. The NID_md5_sha1 codepath wasn't quite doing this right. Reviewed-by: Kurt Roeckx Reviewed-by: Rich Salz GH: #1474 (cherry picked from commit 608a026494c1e7a14f6d6cfcc5e4994fe2728836) Implemented via this pull request: https://github.com/openssl/openssl/pull/1474 So, based on the above description, it appears that older versions of OpenSSL were unduly lenient in tolerating incorrectly formatted signatures. As a security hardening measure that tolerance was removed. If you want to know more then David Benjamin may be able to expand. Please note that CMS countersignatures made using a specific Symantec server (specifically to timestamp the original CMS signature with a long-valid signed timestamp) happened to use a different PKCS#1.x signature format until very recently. This signature had a different but similar input to the raw RSA algorithm, and was only ever done with Sha1RSA. According to my notes, this format was only ever used with sha1RSA and md5RSA, In this format, the DER encoding and hash OID is skipped, and instead the raw 20 or 16 byte hash is placed where the DER encoded tuple should be. The surrounding padding was apparently the same is in PKCS#1.5 signatures, as was the OIDs identifying this algorithm. I don't know if an older PKCS#1 document (before 1.5) actually specified this format, only that is was present in the wild. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
Re: install error with linux mint 19.1
On 25/03/2019 22:53, sebastien wrote: hi in a terminal I've got this error with |openssl version openssl: /usr/lib/x86_64-linux-gnu/libssl.so.1.1: version `OPENSSL_1_1_1' not found (required by openssl) openssl: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1: version `OPENSSL_1_1_1' not found (required by openssl) can you please help me ? | I guess the files |/usr/lib/x86_64-linux-gnu/libssl.so.1.1 and ||/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1|||are the system installed OpenSSL 1.1.0 libraries and your freshly compiled openssl 1.1.1 program is is trying to load them instead of it's own version 1.1.1 libraries. If so, try testing withthe command LD_LIBRARY_PATH=/home/your/openssl-1.1.1-build-dir/somewhere openssl version to force use of your not-yet-installed OpenSSL 1.1.1 libraries. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
