Re: SSL_accept doesn't retry BIO_write
> Now I treat the flush as 'OpenSSL isn't interested in the result > of the last write anymore'. I'm not sure this assumption is correct, > but it seems to work... (Well, it could cause duplicate messages It does not sound correct. Might be true for a read. But, for a write, I'd think it would mean fflush(). What do your BIO functions do for UDP that the existing set of UDP BIO don't do? I have outstanding patches here. signature.asc Description: PGP signature
Re: Upgrading OpenSSL on Windows 10
Steven_M.irc via openssl-users wrote: > Hi Michael, Thanks very much for replying to my e-mail/post. I > apologize for the lateness of my reply. >> This is not true in the general case. There are applications which are >> available on Linux which do not use the distribution's package >> manager. There are applications which use their own OpenSSL build, >> possibly linked statically or linked into one of their own shared >> objects or with the OpenSSL shared objects renamed. Linux >> distributions have not magically solved the problem of keeping all >> software on the system current. > That's disheartening. My next computer will be running Linux and I was > thinking that (as long as I stick to installing software from > appropriate repositories) my update worries would be over soon. It's not specific to Linux. Almost every single "big" application (Chrome, Firefox, OpenOffice) brings their own shared objects. Some of them contain security mechanisms. My impression is that you have just enough knowledge to be dangerous. >> It is possible, with relatively little effort, to find all the copies >> of the OpenSSL DLLs under their usual names on a system > Could you please provide me with a list of the usual names? I've got a > lot of libssl DLL's on my system, but I'm not sure if they're part of > OpenSSL or some other implementation of SSL. no, I can't/won't. Two reasons: 1) I can't because they don't have "usual names", 2) you should rely on your distribution to do the updates, and if you install packages using other means, then you should rely on those mechanisms. If someone tells you to "telnet fobar.com|sh", then you should be concerned that they are probably not clueful enough to keep your up-to-date. >> I'm not sure OpenSSL versions should be particularly high on anyone's >> priority list. > As I understand it, OpenSSL is responsible for establishing HTTPS > connections, the primary protocol for ensuring security and > authenticity over the Internet, and you *don't* think OpenSSL versions > should be a high priority? I don't understand your lack of alarm here. 1) Bugs show up everywhere. You should be concerned about all libraries that do all sorts of things. 2) Browsers tend to bring their own TLS implementation, which they auto-update. 3) Since your desktop is a client systems, it probably isn't subject to attack. >> What are you actually trying to accomplish? What's your task? Your >> threat model? > I want to be able to trust the HTTPS connections between my PC and > servers on the Internet again; whether I'm using a browser, a software > installer (that downloads data from the Internet before installing), a > peer-to-peer application, or any other network application. You can/should trust them as much this year as you did in 1997.
Re: porting openssl to vxWorks
> I would like to know what is the procedure to build the openssl to > vxWorks/Intel platform? The toolchain is available on windows (most > likely I will need to use cygwin) I suggest that if you paid Vxworks for software, that they ought to provide you with a supported TLS implementation. Or, hire a consultant. Open source really can't afford to chase proprietary platforms. signature.asc Description: PGP signature
Re: CA/Server configuration
Cyprus Socialite wrote: > I am looking to clarify some conceptual and practical questions I've > accumulated while trying to configure a private 'Root CA - Intermediate > CA - Server' setup. Most of my confusion revolves around the Okay. (The word out there is "Intermediate CA" is a term best used in the context of Bridge/Federation of CAs, and that the term "Subordinate CA" is preferred in the original specifications. I think you are creating a subordinate CA) I think that you have gone some distance and entered into questions which I have very little opinion, and maybe nobody else does other than to observe what choices others have made. Bob, Henk and I maintain two IETF internet-draft repos whose goal it is to act as a demonstration of build two-level ECDSA and EDDSA CA+subordinate. (We never intend to publish as RFC, but preferred ID format) They are at: https://github.com/mcr/draft-moskowitz-ecdsa-pki-1 https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-10 https://github.com/rgmhtt/draft-moskowitz-eddsa-pki > Secondly, how is the absence of a configuration field/section/extension > handled? Does it default to some value (e.g. from /etc/ssl/openssl.cnf) It defaults to whatever openssl.cnf you have pointed to. > or simply remain empty? For example, if I have no interest in OCSP > functionality, is the non-provision of all of the related fields enough > to prevent my certificates being declared invalid because CRL requests > fail? yes. > Thirdly, I would like to understand the difference between the 'digest' > and the 'cipher' and what roles they perform in the communication > process, especially in relation to the actual signing algorithm. As an > aside: I've noticed that using any of the `sha3-*` digests somehow > prevents Windows 10 from verifying my certificates. cipher would not be used in a CA. I would guess Windows10 does not support SHA3? > Onto more practical concerns, I am thoroughly confused by how many > OpenSSL tools seemingly perform the same tasks. For example, one can Yes, because the "openssl" tool is not really intended to be for production. It exists mostly to allow the libraries to be configured and tested. So, it evolved based upon the need of the day, not any master design. I've argued for splitting much of the higher-layer functions that it does into a different git repo, as the tool is too intimate with the libraries, and the continue to be things you can't (easily) do programatically, but the tools do. > Finally, if anyone happens to be in possession of an exhaustive > configuration file that includes *all* possible sections and fields > supported by OpenSSL, I would very much appreciate a copy! Not me. A Xmas-Lights configuration would be interested to look at, but likely more confusing than useful. signature.asc Description: PGP signature
Re: How to reject a certificate with access_denied?
Matt Caswell wrote: > On 06/06/2022 18:08, Christian Schmidt wrote: >> Hi, >> I am building a server application that allows a user to log in by >> providing a certificate. In order to do custom checks, I have added a >> verify callback to my code to check the certificate on top of its >> cryptographic features (CA Valid, etc). >> If the certificate does not pass my extended checks, I would like to >> return the access_denied alert as per RFC8446 section 6.2: >> access_denied: A valid certificate or PSK was received, but when >> access control was applied, the sender decided not to proceed with >> negotiation. >> However, I can't find a way to generate this alert in openssl, although >> openssl can handle receiving it. >> How do I make a callback return a non-defined (as in not defined in the >> headers) alert? > This is not currently possible. > OpenSSL has an internal table which maps verify errors to TLS alerts: > https://github.com/openssl/openssl/blob/9f3626f2473bdce53e85eba96e502e950e29e16f/ssl/statem/statem_lib.c#L1350-L1394 > Unfortunately there are no entries in this table that map to the > access_denied alert. Would extensions to this list be welcome? Should Christian send a PR?
Re: How to create a SAN certificate
Henning Svane wrote: > I am using OpenSSL 1.1.1f Is there a way to make a SAN certificate > based on the CSR I have created in Exchange. I need a self-signed > certificate for testing. I'm not exactly sure what you think a SAN certificate is. I guess one with a SubjectAltName extension. Mostly, all certificates have that these days, but whether or not the Subject is entirely filled out is a different question. To form a self-signed certificate from a CSR, use openssl req. You may need a configuration file, serial number, expiry and algorithm. You'll need access to the private key. See: https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki#section-4.2 Some of us maintain a document on generated test CAs for ECDSA and EDDSA key types at: https://github.com/henkbirkholz/draft-moskowitz-ecdsa-pki while it is in the form of an IETF ID, it is not intended for publication. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature
Re: OpenSSL 3.0 different behaviour on smaller DH groups?
Simon Chopin wrote: > This test suite fails several times with a failed call to > EVP_PKEY_derive_set_peer, without much more details: > https://github.com/net-ssh/net-ssh/blob/master/test/transport/kex/test_diffie_hellman_group14_sha1.rb > However, the *exact same* test suite works, with the only difference > being that the failing suite uses the DH group 14, which is 2048bits, > whereas the one that passes uses the group 1, which the Internet tells > me is 768bits. DH groups of 768bits are considered too weak. I wonder if openssl 3 is declining to do anymore, and/or has been compiled with an option to drop support for that size. (I have no knowledge of that part of openssl) signature.asc Description: PGP signature
Re: looking for properly configured Windows VMs
Dr. Matthias St. Pierre wrote: >> I see lots of logs. >> Maybe it's private to me. > The link is not private, but it expires after a short amount of > time. The timeout is visible in the URL (after url-decoding it): https://junk.sandelman.ca/junk/logs_53889.zip If that's useful to someone. lots of stuff inside, including... 28510 2022-04-02 22:02 shared (windows-2019, win32, VC-WIN32 --strict-warnings no-fips)/7_config.txt 29474 2022-04-02 22:02 shared (windows-2019, win32, VC-WIN32 --strict-warnings no-fips)/8_build.txt 2414 2022-04-02 22:02 shared (windows-2019, win32, VC-WIN32 --strict-warnings no-fips)/1_Set up job.txt 59 2022-04-02 22:02 shared (windows-2019, win32, VC-WIN32 --strict-warnings no-fips)/21_Complete job.txt 44066 2022-04-02 22:02 shared (windows-2019, win32, VC-WIN32 --strict-warnings no-fips)/2_Run actionscheck...@v2.txt 13574 2022-04-02 22:02 shared (windows-2019, win32, VC-WIN32 --strict-warnings no-fips)/4_Run ilammysetup-n...@v1.txt 13780 2022-04-02 22:02 shared (windows-2019, win64, VC-WIN64A enable-fips)/4_Run ilammysetup-n...@v1.txt 2414 2022-04-02 22:02 shared (windows-2019, win64, VC-WIN64A enable-fips)/1_Set up job.txt 42074 2022-04-02 22:02 shared (windows-2019, win64, VC-WIN64A enable-fips)/8_build.txt 29114 2022-04-02 22:02 shared (windows-2019, win64, VC-WIN64A enable-fips)/7_config.txt 2992 2022-04-02 22:02 shared (windows-2019, win64, VC-WIN64A enable-fips)/3_Run ilammymsvc-dev-...@v1.txt 12527 2022-04-02 22:02 shared (windows-2022, win32, VC-WIN32 --strict-warnings no-fips)/6_prepare the build directory.txt 44524 2022-04-02 22:02 shared (windows-2022, win32, VC-WIN32 --strict-warnings no-fips)/2_Run actionscheck...@v2.txt 2933 2022-04-02 22:02 shared (windows-2022, win32, VC-WIN32 --strict-warnings no-fips)/3_Run ilammymsvc-dev-...@v1.txt 19871 2022-04-02 22:02 shared (windows-2022, win32, VC-WIN32 --strict-warnings no-fips)/5_Run shogo82148actions-setup-p...@v1.txt 1183 2022-04-02 22:02 shared (windows-2022, win32, VC-WIN32 --strict-warnings no-fips)/20_Post Run actionscheck...@v2.txt 12365 2022-04-02 22:02 shared (windows-2022, win64, VC-WIN64A enable-fips)/4_Run ilammysetup-n...@v1.txt 12683 2022-04-02 22:02 shared (windows-2022, win64, VC-WIN64A enable-fips)/6_prepare the build directory.txt signature.asc Description: PGP signature
Re: looking for properly configured Windows VMs
Michael Wojcik wrote: >> > View results: https://github.com/openssl/openssl/actions/runs/2073285321 >> >> I'll take a look when I get a chance to see if anything jumps out. I >> haven't had to deal with IPv6 raw or UDP programming in Windows yet, but I >> do a fair bit with Windows networking development in general. > Logs have been deleted, unfortunately. I see lots of logs. Maybe it's private to me. https://pipelines.actions.githubusercontent.com/serviceHosts/b9f3f541-e29c-4063-98e5-69c2154bc13f/_apis/pipelines/1/runs/53889/signedlogcontent/10?urlExpires=2022-04-02T15%3A36%3A04.2664486Z=HMACV1=J9eXW05FxMynRtIZFhvnWKNDCJtYBmnlPPcMQe5jPj0%3D I got a logs.zip that I'll share as soon it finishes downloading over this rather slow coffee shop wifi. signature.asc Description: PGP signature
Re: [openssl/openssl] bio_dgram vs IPv6
Michael Wojcik wrote: > Actually, in the context of #if expressions, unrecognized tokens expand to 0 anyway: > After all replacements due to macro expansion and the defined unary > operator have been performed, all remaining identifiers are replaced > with the pp-number 0... > (ISO 9899:1999 6.10.1 #3) Yes, but that generates a warning, and then error via -Werror with some set of compile options that at least one CI run uses. signature.asc Description: PGP signature
looking for properly configured Windows VMs
Attempts to make bss_dgram.c compile with the right IPv6 include for Windows are not going well. Some of the jobs actually die before my test case even runs, but at least, I guess they compile bss_dgram.c Others (the shared ones) seem to fail completely to compile bss_dgram.c I haven't run a compile on DOS since the days of djcpp... I wonder if anyone has VM images with the right OS and compilation tools installed? (I think the license situation would be fine if run on EC2) The day-long cycle, making a change and then waiting for CI to give an opinion is just too slow. (I didn't know WIN32 was still even thing... I guess Windows ME still uses it maybe.) Subject: Re: [openssl/openssl] PR run failed: Windows GitHub CI - bio_dgram uses recvmsg/sendmsg to retrieve destination and set origin address (41cc92c) View results: https://github.com/openssl/openssl/actions/runs/2073285321 Jobs: * minimal (windows-2019) cancelled (12 annotations) * minimal (windows-2022) failed (12 annotations) * plain (windows-2019) cancelled (2 annotations) * plain (windows-2022) failed (1 annotation) * shared (windows-2019, win64, VC-WIN64A enable-fips) failed (1 annotation) * shared (windows-2019, win32, VC-WIN32 --strict-warnings no-fips) cancelled (2 annotations) * shared (windows-2022, win64, VC-WIN64A enable-fips) cancelled (2 annotations) * shared (windows-2022, win32, VC-WIN32 --strict-warnings no-fips) cancelled (2 annotations) signature.asc Description: PGP signature
Re: [openssl/openssl] bio_dgram vs IPv6
The clang-9 test fails with: # ERROR: @ test/bio_dgram_test_helpers.c:150 # failed to v6 bind socket: Permission denied # # # OPENSSL_TEST_RAND_ORDER=1648577511 not ok 2 - iteration 1 https://github.com/mcr/openssl/runs/5741887864?check_suite_focus=true The other clang-XX tests seem to run fine. This smells like the problem with TRAVIS where IPv6 was not enabled in the Google VMs, but we aren't using those anymore. It does not bind specific sockets (lets kernel choose), so there shouldn't a conflict between test cases. Anyway, if that were the case, I'd expect to see in-use error rather than permission denied. Smells to me like someone has restricted network sockets in order to avoid being used as an attack system. signature.asc Description: PGP signature
Re: [openssl/openssl] bio_dgram vs IPv6
Michael Wojcik wrote: > #if defined OPENSSL_SYS_WINDOWS > # include > #else > # include > #endif But, don't all the OPENSSL_* macros expand to 0/1, anyway, so we actually just want #if OPENSSL_SYS_WINDOWS? > (Note C does not require the argument of the operator "defined" to be > parenthesized. Doing so just adds visual noise. ISO 9899-1999 6.10.1 > #1.) Thank you. I've updated bss_dgram.c, squashed against the last commit relating to USE_IPV6 and pushed. -- ] 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[
Re: [openssl/openssl] bio_dgram vs IPv6
Matt Caswell wrote: > There is already code in bss_dgram.c that is conditionally compiled on > OPENSSL_USE_IPV6. Is it reasonable to assume that if AF_INET6 is > defined then ip6.h exists? I think so, so I changed that code, and also made it consistently use OPENSSL_USE_IPV6, rather than having AF_INET6 sprinkled in. I don't know how much to squash all of this down again. signature.asc Description: PGP signature
Re: [openssl/openssl] bio_dgram vs IPv6
Matt Caswell wrote: >> Matt Caswell wrote: > Nit; We insert an >> extra space when enclosed within a "#if", i.e. >> >> I assume that this applies recursively? > Yes. >> I think that in some cases the indent could be quite deep. > It hasn't been a major issue so far. I'm sure that I need to make another pass to get it perfect. Once the issues in my other email are resolved, I will squash it all down to one commit, I think. I had tried up to now to keep, for instance, the *BSD code as a separate commit to make it easier to review. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature
Re: [openssl/openssl] bio_dgram vs IPv6
Michael Wojcik wrote: > The RFC specifically mentions using this API to retrieve and set > addresses, so it seems like a fix for issue 5257 does need to use it, > if that's to be done in a portable way. > 3542 is only Informational, but I'd expect most or all platforms with > IPv6 support to conform to it. The issue isn't whether we can expect it to be standard. The issue is what we can use as a signal that the header exists. To date, I don't think that openssl has had to know if IPv6 existed or not on a particular platform. signature.asc Description: PGP signature
bss_dgram changes and Re: run-checker NO DGRAM and test cases
I've continued to work on:
https://github.com/openssl/openssl/pull/5257
I'm summarizing this here because the pull request is now very convoluted to
follow.
a) It's rebased to openssl-3.1-dev, although now 30 commits behind head since
last week, but should be easy to bring it to the tip.
b) I've remove TRAVIS_NO_IPV6, as we don't use Travis-CI anymore.
c) there have been comments about whether ip6.h can be included or not, and
it seems to me that if there are systems that have posix sockets, but don't
have
IPv6 support, that they are very non-mainstream, and probably not in CI
today. I don't know what #ifdef will be relevant yet.
d) I've tried to fix my build.info to avoid testing on no-sock, as I'm told
that dgram is off when sock is off, but I am getting failure cases that I
don't quite understand. Maybe it's not always true?
Works fine on linux-x86_64, but seems to fail for cross compile cases,
such as:
https://github.com/mcr/openssl/runs/5616934201?check_suite_focus=true
This test case explicitely does no-dgram, yet it tries to run
my test case which hasn't been built.
https://github.com/mcr/openssl/runs/5616935614?check_suite_focus=true
"minimal" Appears to also have sock, and I guess !dgram.
https://github.com/mcr/openssl/runs/5616934286?check_suite_focus=true
all sorts of cross-compiles: mips, m68k, hppa...
Proably also sock and !dgram?
https://github.com/mcr/openssl/runs/5616934565?check_suite_focus=true
Explicit no-sock, but it doesn't appear to have turned off dgram.a
e) added man page for BIO_dgram_{set,get}_{origin,dest}
I wind up writing another pull request on how to do the documentation.
See: https://github.com/openssl/openssl/pull/17926
and that resulted in: https://github.com/openssl/openssl/pull/17933
f) I rewrote the dgram_read_unconnected_v4 to do the #ifdef within the
function. It's a mess. I wouldn't want to maintain it like that!!!
I agree that there is some duplicate for() loop and stuff, but for IPv4,
it's a mess of different options on difference OSes with different
structures.
When sometime writes the Windows WSARecvMsg() version it will be an even
bigger mess. (I don't have the knowledge or tools to test such a thing)
https://github.com/openssl/openssl/pull/5257/commits/64d181a331d0fc8d99d4f54744403003afee5c78
The commit is above.
I tested this with BSD-generic64 on a NetBSD 9.2 VM, which I happened to have
around. I think that I got it right. I couldn't have done it within the
#ifdef first thing though.
g) I've tried to refactor the bio_write_test and bio_read_test into using
some common helpers. I'm using read()/write() for the side which is not
being tested to avoid using the code under test in the test.
I'm not really happy with the result, and I think that the results are
less clearly understood.
This pull request is a prequel to another one involves making DTLS more like
accept(2) / TLS.
My target application is in Ruby-on-Rails, and the ruby-openssl gem is not
yet fully 3.x happy.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
Re: [openssl/openssl] bio_dgram vs IPv6
I'm working on dealing with Matt's detailed review. This issue seems bigger than the github issue. https://github.com/openssl/openssl/pull/5257 about: #include matt> This remains an issue. It's unclear to me whether all of these headers will matt> be available on all platforms. At least in some files we wrap some of these matt> in an "ifdef OPENSSL_SYS_UNIX". We have, as yet, never used netinet/ip6.h - matt> so I am concerned it may not be universally available on all the platforms matt> that we might need to support. These would platforms that are not in the CI. I agree that IPv6 not be present. I could put all the IPv6 code behind some #ifndef IPV6_MISSING which would presently be never defined, but could be added later to ./Configure if/when we figure out where it's a problem. Matt Caswell wrote: > Nit; We insert an extra space when enclosed within a "#if", i.e. I assume that this applies recursively? I think that in some cases the indent could be quite deep. I wonder if there an emacs mode that does this I browsed the man page for indent(1), but I didn't find an option for this year, but I'll look again closer. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
Re: run-checker NO DGRAM and test cases
Hi, could/should someone run sort on util/other.syms? signature.asc Description: PGP signature
Re: run-checker NO DGRAM and test cases
Tomas Mraz wrote:
>> Perhaps my use of: IF[{- !$disabled{dgram} -}]
>>
>> is wrong in some way.
> You've included the bio_write_test and bio_read_test also on the bare
> PROGRAMS{noinst} assignment. You need to remove them from there.
> Interestingly the http_test is included there as well which means it
> will also be always compiled.
Ah, I was a bit dim, but I understand now.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
Re: run-checker NO DGRAM and test cases
Tomas Mraz wrote:
>> Should the test *ALSO* ifdef itself out if OPENSSL_NO_DGRAM is
>> defined?
> No, that's not necessary as they won't be built at all with the
> build.info change above.
I didn't find this to be true. The source file still got built, and linked,
and that failed.
I had to add an ifdef to the source file. Please see:
https://github.com/mcr/openssl/commit/2ae78377969d939d5eedc39ca0c22d914f739e93
Perhaps my use of:
IF[{- !$disabled{dgram} -}]
is wrong in some way.
signature.asc
Description: PGP signature
Re: run-checker NO DGRAM and test cases
Tomas Mraz wrote:
>> I figured out that this means that ./Configure should have "no-dgram"
>> appended to it. That seems to result in OPENSSL_NO_DGRAM being
>> defined.
>>
>> My test case naturally does not compile for that.
>>
>> Should my test case just be surrounded by #ifndef OPENSSL_NO_DGRAM
>> from top to bottom (leaving...?), or is there something more
>> sophisticated that should go into build.info in order to skip the test
>> in that configuration?
> Please look at the other examples in tests/build.info - there are
> things disabled for no-sock and other stuff. But you'll also need to
> skip the test in the perl test recipe.
I thought it was shell script, but now that I look more at it, I guess it is
a custom DSL.
IF[{- !$disabled{dgram} -}]
PROGRAMS{noinst}=bio_write_test
ENDIF
SOURCE[bio_write_test]=bio_write_test.c
INCLUDE[bio_write_test]=../include ../apps/include
DEPEND[bio_write_test]=../libcrypto libtestutil.a
Should I repeat the test for the two programs, or should I group into a
single IF for both programs?
i.e.
IF[{- !$disabled{dgram} -}]
PROGRAMS{noinst}=bio_write_test bio_read_test
ENDIF
I guess maybe the tests could be named with dgram in the file name, since
that's all they do. Should the test *ALSO* ifdef itself out if
OPENSSL_NO_DGRAM is defined?
It already does:
#if defined(_WIN32)
int setup_tests(void)
{
return 1;
}
...
signature.asc
Description: PGP signature
run-checker NO DGRAM and test cases
One of the run checkers is marked "no dgram". https://github.com/mcr/openssl/runs/5563998914?check_suite_focus=true I figured out that this means that ./Configure should have "no-dgram" appended to it. That seems to result in OPENSSL_NO_DGRAM being defined. My test case naturally does not compile for that. Should my test case just be surrounded by #ifndef OPENSSL_NO_DGRAM from top to bottom (leaving...?), or is there something more sophisticated that should go into build.info in order to skip the test in that configuration? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature
Re: PKCS#10 CSR generation and bulky crypto library - Re: Questions about legacy apps/req.c code
A problem that I have with apps/req.c is that it is hardly a good reference for how to use the API calls. I think, ideally, that all of openssl.cnf should be entirely an artifact of the apps, but there are (still, I think) things that can only by constructing some openssl.cnf configuration and sending that down. Many of those calls are not documented, but many wrappers (ruby's openssl for instance) continue to use. I posted a notion a few years ago that the apps/* should be split off into a new repo, should use only documented API calls, and should evolve separately from the core libssl. This is a documentation and d06f00d'ing exercise. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature
Re: useless search box on openssl.org
Jordan Brown wrote: > On 11/18/2021 2:31 PM, Dr Paul Dale wrote: >> Apart from keeping dross around from old unsupported versions, I don't >> think there is much the project can do about this unfortunately. > Unfortunately, people often feel the need to continue using a particular > version of a piece of software long after its authors thought it dead. > It would be nice to keep old documentation around for them, since the > cost is low. > Also, if one is trying to update a piece of existing software to use a > new version of the library, it may sometimes be necessary to look at old > documentation to see how the old version worked, so as to understand the > software and work out how it should work with the new library. Exactly... Such programmers might find compiling the old man pages difficult, particularly since the build this in a Linux VM on your lame desktop OS might not easily let you view HTML. I have seen this way too often. The younglings don't learn about the "man" command :-( signature.asc Description: PGP signature
Re: useless search box on openssl.org
Dr Paul Dale wrote: > Apart from keeping dross around from old unsupported versions, I don't think > there is much the project can do about this unfortunately. Well, the project could avoid deleting man pages from the server. If they were worth posting, then they are worth preserving? Instead of deleting, one could update in place. That might mean don't post "man1.1.0", instead post it as "man1.1", and update it with man 1.1.0, 1.1.1, content. The pages had better say which version they are internally. They seem to do this already. This assumes that having man1.1.0 and 1.1.1 online at the same time has no value, and that if there are any changes within, that they are explained by the man page themselves. This probably has much better SEO. Post and delete them as you do now, but insert symlinks. This is really cheap to do, but has the downside that the content appears multiple times, and the search engines will continue to prefer the older path. Post and delete them as you do now, but provide 301 redirects. I wondered if there was an apache module that could turn symlinks into 301s, but googling just found others with the same question. Since "man1.1.0" and "man1.1.1" are pretty close, the Apache mod_speling module may be able to do this. Post and delete them as before, but have a better 404 handler. Other more complex thoughts: don't use google to search, do something inhouse. (hello... 1997 is calling). Use a complex google search restriction so that one could even search within a documentation set. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature
useless search box on openssl.org
If you go to any page on openssl.org, and using the search box, you enter, say: X509_get_ext_d2i then you go to: https://www.google.com/search?sitesearch=www.openssl.org=X509_get_ext_d2i which gives me, aas the top link: X509V3_get_d2i - OpenSSLhttps://www.openssl.org › man3 › X509_get_ext_d2i X509V3_get_ext_d2i() looks for an extension with OID nid in the extensions x and, if found, decodes it. If idx is NULL then only one occurrence of an extension ... which is a link to: https://www.openssl.org/docs/man1.1.0/man3/X509_get_ext_d2i.html which is Page Not Found. I guess because man1.1.1 is now current. With no forwarder. signature.asc Description: PGP signature
Re: "DST Root CA X3" expiry workaround for OpenSSL 1.0.1, 1.0.0 and 0.9.8 client applications
I got a call on Thursday from my mom asking why Apple Mail couldn't SMTP deliver to my LE signed SMTP server. She forgot how to start teamviewer, so a Saturday morning trip to the small town she lives in later... and it she looks like a problem with anchors. On a brand new MacOS system from this year. (Her old iMac had long sinced reached it's maximum OS level and was sadly, replaced) The machine did want to apply updates, which allowed, but I don't know if those updates solved the problem because I had already overridden things. I was surprised anyway, and I'm just posting this as a datapoint. I don't have many details. I don't know what libraries Apple Mail uses. signature.asc Description: PGP signature
Re: OpenSSL SSL_CTX_set_default_verify_paths Slow
Jay Foster wrote: > While migrating some applications from OpenSSL 1.0.2 (and 1.1.1) to > 3.0.0, I have noticed that the SSL_CTX_set_default_verify_paths() > function is much slower in 3.0.0. In 1.0.0 it would take about 0.1 > seconds and in 3.0.0 it takes over 3 seconds. Based upon your straces, the time is spend in the OS. Are you running this on the same system? That's still very slow... I wonder if you have a failing disk. -- ] 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[ signature.asc Description: PGP signature
Re: CMS_sign/CMS_final streaming
Dirk-Willem van Gulik wrote: > I have very large globs of on the fly generated data that are to be > signed and output as a base64 payload followed by a separate PKCS#7 > package with a detached signature at the end of the transmission[1]. > I’d like to avoid CMS_sign/CMS_final having to rely on a BIO_s_mem(), > disk-storage or similar. > But rather simply do something like calculating the SHA256 as the > payload is streamed out. And then have a CMS_sign/final do the deed > with that SHA256 rather than a BIO. My understanding from reading the CMS man pages is that it is done by providing a NULL value for the content. I haven't done this myself, but encountered the hints at, for instance: https://www.openssl.org/docs/man1.1.1/man3/CMS_final.html I'd go look in the tests directory for some code that calls CMS_final(), and maybe that will provide a workable example for you. -- ] 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[ signature.asc Description: PGP signature
3.0 beta1 feedback about (shared) library names
I downloaded and compiled opensssl 3.0.0-beta1 from git today.
I installed into a private prefix.
While my debian desktop system has:
%ls -l /usr/lib/x86_64-linux-gnu/libssl*
-rw-r--r-- 1 root root 357056 Jul 8 2020 /usr/lib/x86_64-linux-gnu/libssl3.so
-rw-r--r-- 1 root root 1000534 Feb 16 17:08 /usr/lib/x86_64-linux-gnu/libssl.a
lrwxrwxrwx 1 root root 13 Feb 16 17:08 /usr/lib/x86_64-linux-gnu/libssl.so
-> libssl.so.1.1
-rw-r--r-- 1 root root 435704 Jul 4 2017
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
-rw-r--r-- 1 root root 431232 Dec 23 2019
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
-rw-r--r-- 1 root root 593696 Feb 16 17:08
/usr/lib/x86_64-linux-gnu/libssl.so.1.1
%ls -l /usr/lib/x86_64-linux-gnu/libcrypto*
-rw-r--r-- 1 root root 5399144 Feb 16 17:08
/usr/lib/x86_64-linux-gnu/libcrypto.a
lrwxrwxrwx 1 root root 16 Feb 16 17:08
/usr/lib/x86_64-linux-gnu/libcrypto.so -> libcrypto.so.1.1
-rw-r--r-- 1 root root 2494464 Jul 4 2017
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
-rw-r--r-- 1 root root 2504576 Dec 23 2019
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2
-rw-r--r-- 1 root root 3031904 Feb 16 17:08
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
WTF is libssl3.so? I still don't know, but:
%dpkg -S /usr/lib/x86_64-linux-gnu/libssl3.so
libnss3:amd64: /usr/lib/x86_64-linux-gnu/libssl3.so
something up there that should be concerning, because maybe it will cause
confusion.
My newly installed openssl 3 has:
%ls -l /sandel/3rd/openssl3/lib
total 16188
drwxr-xr-x 2 mcr mcr4096 Jun 21 21:29 engines-3/
-rw-r--r-- 1 mcr mcr 9307420 Jun 21 21:29 libcrypto.a
lrwxrwxrwx 1 mcr mcr 14 Jun 21 21:29 libcrypto.so -> libcrypto.so.3*
-rwxr-xr-x 1 mcr mcr 5205856 Jun 21 21:29 libcrypto.so.3*
-rw-r--r-- 1 mcr mcr 1251782 Jun 21 21:29 libssl.a
lrwxrwxrwx 1 mcr mcr 11 Jun 21 21:29 libssl.so -> libssl.so.3*
-rwxr-xr-x 1 mcr mcr 794496 Jun 21 21:29 libssl.so.3*
drwxr-xr-x 2 mcr mcr4096 Jun 21 21:29 ossl-modules/
drwxr-xr-x 2 mcr mcr4096 Jun 21 21:29 pkgconfig/
So I see that the versioned .so file will be somewhat related to the version.
Distros will be able to ship openssl1.x and openssl3.x shared libraries at
the same time.
But, having both "libssl-dev" and "libssl3-dev" installed at the same time is
going to be a problem.
I think that the differences in ABI may be significant enough that you should
consider calling it "libssl3" and "libcrypto3". Yeah, maybe that's uncool,
but it may be pragmatic.
{ps: I am working on the ruby openssl library next to see what happens}
--
] 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[
signature.asc
Description: PGP signature
Re: Project direction
Angus Robertson - Magenta Systems Ltd wrote: > Also, there is an assumption OpenSSL is only used by other C developers, > by the use of public macros that are not usable in any other language. > BoringSSL replaced macros with exports and OpenSSL should consider > doing the same. This. > There needs to be more task oriented documentation, for instance > collecting the APIs needed to create a CSR or certificate, using APIs > rather than command line tools which is where much of the documentation > currently resides. For instance there is no documentation about > building a stack of extensions to add SANs to requests and certificates > so a lot of research is needed to adds SANs to a certificate. My claim is that much of the "applications" should be removed from the core system, and should be re-implemented in a cleaner way using the APIs. I.e. into a separate git repo with it's own release schedule. They should serve as exemplars for using the APIs, which they are often are not. In particular, the way that many things are only doable via "configuration file" is a serious problem. Yes, the applications are used as part of the tests, but I'm not saying that they shouldn't be pulled in as a github. Could Perl wrapper be used for more? Could it be used exclusively? (No calls out to "openssl ca" to generate a certificate...) The tests do not serve as particularly good examplars, because of the mix of C and perl, sometimes the perl is just running some .c code that was compiled... sometimes not. -- ] 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[ signature.asc Description: PGP signature
Re: SMIME signed message verification
Harald Koch wrote: >> Am 29.10.2020 um 14:12 schrieb Michael Richardson >>> - "Unable to verify content integrity: Missing data" >>> - "The system is unable to find out the sign algorithm of the inbound message" >> >>> I digged a bit deeper into the ASN1 data („cat signature.base64 | base64 -d | openssl asn1parse -inform DER" ), leading to my assumption that the algorithm provided for signature contained differs: >>> - openSSL indicates „rsaEncryption" >>> - Java indicates „sha512WithRSAEncryption" >> >> The first error you got seems inconsistent with this problem. >> Is is possible that one of you are sending CMS structures with >> out-of-band content? > Yes, the signed message is contained in a HTTP(S) multipart request > with more payload and header information, sure. The only different part > is the signed content, all other content has been manually checked, > they are exactly the same. May it be possible that the CMS data which > openSSL generates is much bigger due to unneeded certificate > information, which makes the Java process stumble over the input? so, do have detached content then? And MIME and HTTP is involved? My bet is that you have CRLF/LF issues, which you might not see unless you look at the raw packets --- after the TLS is removed, which is a hassle, but there is a way in openssl to get that data put somewhere, but I can't recall what it is. -- ] 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[ signature.asc Description: PGP signature
Re: SMIME signed message verification
Harald Koch wrote: > my task is to sign a message in C for SMIME exchange, which works as > expected and openSSL is self-fulfilling with itself in successful > verification (and unsuccessful in produced errors as expected). I've > tested PKCS7 SMIME functions, as well as CMS ones, leading to the same > result: the reference software endpoints (both written in Java; at > least one uses BuncyCastle) are unable to verify the signature. See > below the BASE64 blocks of a successful reference signature, and an > unsuccessful openSSL variant of the same message, both signed with the > same certificate and private key. The error message extracted from the > Java implementations are: I have exchanged CMS signed artifacts with Java implementations. I have CC'ed the author of the Java code to understand if they use BouncyCastle or are using an OpenSSL wrapper in Java code. > - "Unable to verify content integrity: Missing data" > - "The system is unable to find out the sign algorithm of the inbound message" > I digged a bit deeper into the ASN1 data („cat signature.base64 | base64 -d | openssl asn1parse -inform DER" ), leading to my assumption that the algorithm provided for signature contained differs: > - openSSL indicates „rsaEncryption" > - Java indicates „sha512WithRSAEncryption" The first error you got seems inconsistent with this problem. Is is possible that one of you are sending CMS structures with out-of-band content? -- ] 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[ signature.asc Description: PGP signature
Re: Are -DOPENSSLDIR -DENGINESDIR hard coded ?
Dennis Clarke via openssl-users wrote:
> I have been trying to build a debug version with no-asm into a /opt/foo
> directory but I always see :
> -DOPENSSLDIR="\"/usr/local/ssl\""
> and
> -DENGINESDIR="\"/usr/local/lib/engines-1.1\""
> during the compile.
> Are these hard coded in somewhere ?
No, but show us your ./Configure line.
I regularly build into other directories.
For instance:
./Configure --prefix=/sandel/3rd/openssl-dtls-api linux-x86_64
Or:
./Configure --prefix=/usr --openssldir=/usr/lib/ssl
--libdir=lib/linux-x86_64 no-idea no-mdc2 no-rc5 no-zlib no-ssl3
enable-unit-test linux-x86_64
{from a Dockerfile where I want to replace the system copy}
--
] 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[
signature.asc
Description: PGP signature
Re: Cert hot-reloading
Having read through the thread, I think that Viktor is assuming that the private key will always be replaced. My reading of the CABForum push towards 13 month validity, and the LetsEncrypt 90-day process it that private key replacements are not necessarily replaced that often. The shortest *certificate* lifetimes are driven by a desire to eliminate some CRL/OCSP stuff a la RFC 8739 (was draft-ietf-acme-star) Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME) Watching the certificate file and reloading it would suffice for 90% of uses. Viktor suggests using the combined private-key/certificate format. I think that's a undesired constrait. For the paranoid who want to encrypt their private keys and type passphrases when whey reload would probably not like that. It probably also fails if the private key is in an HSM (and you don't replace that private key as often, I imagine). In all algorithms I'm aware of, the public key can be derived from the private key, so we can check if the loaded private key matches the public key in the certificate. (I seem to remember some attack on some systems where doing that checked defeated the attack, but I can't recall which one) So it seems that we can easily use the mis-match of the keys to trigger a check on the private key file, and if we can't load it (passphrase, etc), then we could actually reject reloading the certificate file. The operator has clearly done something wrong, or the file system hasn't caught up to a consistent state... and the operator should do a manual reload/restart. Oh, and while I think that openssl should have some reference code that uses openat(), I rather suggest that this is reference code. Let the application deal with setting up and processing the file update events, and calling OpenSSL to potentially load a new certificate/key pair. OpenSSL should focus on the reference counting needed underneath. -- ] 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[ signature.asc Description: PGP signature
Re: Specify multiple certs for s_server and s_client
John Jiang wrote: > Hi, Can I specify multiple certificates for tools s_server and > s_client? I need to check the certificate selection with > certificate_authorities. > And it looks s_server has no option for certificate_authorities, > however s_client has -requestCAfile for that extension. I believe that s_client and s_server are really intended as testing tools, and if you are getting into more complex situations, you should copy the example, simplify it, and then instrument the callbacks to do the certificate checking that you need. -- ] 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[
Re: distributed secret key
Erich Eckner wrote: > we're looking into setting up a CA with openssl, but we would like to > distribute the secret key amongst multiple persons. We're aware of > Shamir's secret sharing algorithm, but we'd like to know if there is some > algorithm supported by openssl, that fulfills the following requirements > (2 and 3 are not fulfilled by Shamir's algorithm): > 1. Secret key shared amongst N persons, M the key. > 2. No secret material (or parts thereof) needs to be sent around, > preferably not even during creation of the key. So you want to split a secret, but then not send anything to anyone? I don't really understand this at all. I don't think it's physically possible. Maybe you could restate your requirement in another way. > 3. Secret key will not be assembled from the shares for the acutal > operation. E.g. each share operates independently, and the intermediate > result is sent around, after M keyparts operated on it, the signature is > complete and can be used. I guess you want a system where the shares can be added after "exponentiation" rather than before. > If this is not supported by openssl, we're also open for suggestions of > other (open source, free-to-use) software, that can achieve this and > creates standard X.509 certificates (not sure if I termed that correctly). I believe that Phillip Hallam-Baker's Threshold Modes in Elliptic Curves draft-hallambaker-threshold-02 may fullfil your needs. It might even satisfy (2), but I'm not sure it satisfies (1). It may be that you don't need to satisfy (1). I know that Phil has running code, but I don't think it's based upon openssl. -- ] 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[ signature.asc Description: PGP signature
Re: CMS in openssl
Michael Mueller wrote: >> Michael Mueller wrote: >> > We've implemented what I gather can be called a CMS on Linux and >> Windows >> > using openssl evp functions. >> >> I'm not sure why you say it this way. >> OpenSSL includes CMS (RFC3369) support, but I think not until 1.1.0. >> Did you implement RFC3369, or something else? >> >> You don't say if this is email or something else. >> > My bad. I thought CMS could be used as a generic reference to packaging > encrypted messages. > We are not implementing CMS as specified by IETF. > We used the openssl evp functions to quickly improve the security of an > existing proprietary data exchange system. > Now we are being asked if our evp based solution can interoperate with a > system that may support PKCS7. The thought is PKCS7 would be used to > envelope data in a manner similar to how the evp functions operate. I don't think you will find any compatibility. You can use the PKCS7 functions to process that kind of data. Or future proof and use CMS functions to read, and figure out how you will write/send messages. > I suspect that evp functions are not compatible with PKCS7, but I don't > know how to easily confirm this. I also suspect it will be difficult to > explain why they are incompatible. > If evp and PKCS7 are incompatible, we might be asked if we can use PKCS7 > enveloping instead of evp. > Any insights, thoughts, advice, code to read, etc would be appreciated. I think you should consider if you want to move to PKCS7. -- ] 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[ signature.asc Description: PGP signature
Re: CMS in openssl
Michael Mueller wrote: > We've implemented what I gather can be called a CMS on Linux and Windows > using openssl evp functions. I'm not sure why you say it this way. OpenSSL includes CMS (RFC3369) support, but I think not until 1.1.0. Did you implement RFC3369, or something else? You don't say if this is email or something else. > We need to expand this CMS to other systems, on which we have not been able > to build openssl. These other systems have a vendor supplied security > application. This application supports PKCS7. > We are being asked if our evp CMS is interoperable with PKCS7. CMS (RFC3369/2630) is an upward revision to PKCS7 (RFC2315) 1.5. CMS can read PKCS7 messages, but converse is not true. I think it is possible to configure the CMS routines to produce PKCS7 messages, but I didn't do this in my RFC8366 support. I just forklift upgraded to CMS. > If it is possible and more information is required to answer this question, > I'll provide such information. > If not, advice on how to present that argument to management would be > appreciated. You will understand them, but they won't understand you. You may be able to configure your end to generate PKCS7 easily, and it may have little effect. This might degenerate until just using PKCS7 everywhere. The major difference is the eContentType that is lacking in PKCS7. And algorithms: I think that there are few modern algorithms defined for PKCS7. You could easily run in PKCS7 mode until you receive a CMS message from the peer, and then upgrade to CMS. But this winds up in a bid-down attack if both parties run this algorithm, so you'd want to insert some extension that said: "I can do CMS" into your PKCS7 messages. -- ] 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[ signature.asc Description: PGP signature
Re: Resetting DTLS server
On 2019-11-12 10:30 p.m., Patrick Herbst wrote: > > I'm not creating a new socket because it is UDP, and i'm assuming only > one client. If you use a BIO_new_dgram, then you dont need to You assumed one client, and you got one client. What's the problem :-) > Even if i were the "connect" the socket to the clients addr, the > client comes up with the same addr/port combination, so the server's > "connected" UDP socket will continue reading mesgs from the client. I think that it won't work with OpenSSL for more than one DTLS session to occur on the same 5-tuple pair. Whether or not that is correct behaviour according to a specification, I suspect is open to debate. signature.asc Description: OpenPGP digital signature
Re: Resetting DTLS server
On 2019-11-12 9:30 p.m., Patrick Herbst wrote:
> On Tue, Nov 12, 2019 at 3:00 AM Michael Richardson wrote:
>> Close the UDP socket on the client and open a new one to get a new
>> source port.
>> Does that work? I'm not terribly happy with this solution, but it does
>> match what TCP would do.
>>
> In general, here is what i do (assuming only 1 client for proof of
> concept, and skipping some mundane steps)
> also assuming the client is using the same addr/port, so "connect"
> would not make a difference.
so you are showing me your server code, correct, and this is for DTLS,
right?
Do you call DTLSv1_accept()?
You don't seem to be creating a new socket anywhere, or calling
connect() on this socket.
I'm not sure I understand your comment above about connect would not be
a difference.
If your DGRAM socket is not connected, how can you send packets back?
It would be nice
if DTLS code would store the origin of every packet and demux it into
multiple SSL*, but it doesn't work that way.
>
> s=socket(AF_INET, SOCK_DGRAM, 0);
> bind(s, , sizeof(serverAddr));
> ssl=SSL_new(ctx);
> bio=BIO_new_dgram(s, BIO_NOCLOSE);
> SSL_accept(ssl);
>
> while (1) {
> select(FD_SETSIZE, fds, NULL, NULL, NULL);
> if (FD_ISSET(s)) {
> n=SSL_read(ssl, buffer, sizeof(buffer));
> if (n>0) {
> printf("rx: %s\n", buffer);
> } else {
> printf("bad things\n");
> }
> }
> }
>
> What happens is form the Server standpoint, it doesn't know when a
> client restarts. When the client does restart, the server blocks on
> SSL_read while the internals of the library keep reading packets until
> it gets app data... so it ignores another clienthello, but doesn't
> notify the server of that condition.
>
> am i missing something? is this worth fixing in the library? is this
> intended behavior?
signature.asc
Description: OpenPGP digital signature
Re: Resetting DTLS server
On 2019-11-12 7:38 a.m., Patrick Herbst wrote: > If i setup a DTLS server, the client can connect once and send > messages find. but if the client restarts and tries to send data, the > server hangs on SSL_read. How are you handling the sockets on the server? If you are creating a new 5-tuple [bind/connect] socket on the server for each client, and the client then reuses it's socket, then it's trying to speak the old instance on the server. > I'm assuming the server does not like a clienthello message when it is > expecting application data. > > How can the server be made to recover and re-handshake with the > restarted client? Close the UDP socket on the client and open a new one to get a new source port. Does that work? I'm not terribly happy with this solution, but it does match what TCP would do. signature.asc Description: OpenPGP digital signature
debian openssh issue with openssl 1.1.1d
Salvatore Bonaccorso wrote: > - > Debian Security Advisory DSA-4539-2 secur...@debian.org > https://www.debian.org/security/ Salvatore Bonaccorso > October 07, 2019 https://www.debian.org/security/faq > - > Package: openssh > Debian Bug : 941663 > A change introduced in openssl 1.1.1d (which got released as DSA 4539-1) > requires sandboxing features which are not available in Linux kernels > before 3.19, resulting in OpenSSH rejecting connection attempts if I've gone through the changelog for 1.1.1d, but I can't figure out what 1.1.1d would have changed that would have caused this. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
Re: Format and standard for CSR
Robert Moskowitz wrote: > On 8/29/19 9:20 AM, Michael Richardson wrote: >> Robert Moskowitz wrote: >> > I am writing an Internet Draft that will include transmission of a CSR, so I >> > need to reference the proper source. No more sloppy, "well it works...". >> >> > Some digging said it is in PKCS#10 - CSR. But I did not stop with >> > that. >> >> RFC2986 is PKCS10. >> RFC7030 references that, I don't think that there is anything newer. >> But, maybe I've mis-understood your question? > To bring up 7030, yes you have. > 7030 is not something you want to run over a highly constrained network, > involving a highly constrained device. It does provide some good guidelines > for 'completeness'. Is ANIMA using it? And ANIMA is not just constrained > devices. ANIMA BRSKI is an RFC7030 extension. ANIMA constrained-BRSKI (draft-ietf-anima-constrained-voucher) is an extension of ACE's draft-ietf-ace-coaps-est, which is a constrained version of 7030. [Yes, I'm an author on all of those] It still uses CSRs (binary DER, never PEM encoded). > For this project there are strong arguments to do all registration stuff > within HIP messages. At least for initial design. > It is not my job in this project to declare a winner in best CSR format > design. For the initial specification, I need to do a best effort on current > practice. PKCS#10 seems to be that. We are going to be using CSR until we have something like CoID. -- ] 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[ signature.asc Description: PGP signature
Re: Format and standard for CSR
Robert Moskowitz wrote: > I am writing an Internet Draft that will include transmission of a CSR, so I > need to reference the proper source. No more sloppy, "well it works...". > Some digging said it is in PKCS#10 - CSR. But I did not stop with > that. RFC2986 is PKCS10. RFC7030 references that, I don't think that there is anything newer. But, maybe I've mis-understood your question? -- ] 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[
Re: IPv6 address encoding in commonName
Richard Levitte wrote: > On Thu, 15 Aug 2019 00:47:41 +0200, Michael Richardson wrote: >> >> >> Robert Moskowitz wrote: > I am fiddling around >> with an intermediate CA signing cert that the CA's > 'name' is it HIP >> (RFC 7401) HIT which is a valid IPv6 address. Actually a > >> Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to be revised >> soon). >> >> > For a client cert, it would be easy to put the HIT in subjectAltName >> per RFC > 8002 (with a null subjectName), but a CA cert MUST have a >> non-empty > subjectName. >> >> > Thus all I want in this subjectName is commonName with the HIT. > I >> am looking for examples of IPv6 addresses in commonName. >> >> I thought that RFC3779 did exactly what you want, but it does not >> define new Subject DN, but rather a new extension that will be bound >> to the Subject. (I was surprised that RFC3779 was not in the SIDR >> WG's list of documents,but I guess it preceeded the SIDR working >> group, and occured in PKIX) > OpenSSL does support that extension... crypto/x509v3/v3_addr.c (moved > to crypto/x509/v3_addr.c in next major version) is all about that as > far as I can see. > Thanks for bringing that up. Trying to infer some kind of meaning into > commonName would be a mistake (isn't previous such hacks the very > reason we have the subjectAltName extension?) Yes, but we didn't let (intermediate) CAs have an empty subject DN, SAN-only, because we don't have an IssuerAltName for the next level. -- ] 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[ signature.asc Description: PGP signature
Re: IPv6 address encoding in commonName
Robert Moskowitz wrote: > I am fiddling around with an intermediate CA signing cert that the CA's > 'name' is it HIP (RFC 7401) HIT which is a valid IPv6 address. Actually a > Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to be revised soon). > For a client cert, it would be easy to put the HIT in subjectAltName per RFC > 8002 (with a null subjectName), but a CA cert MUST have a non-empty > subjectName. > Thus all I want in this subjectName is commonName with the HIT. > I am looking for examples of IPv6 addresses in commonName. I thought that RFC3779 did exactly what you want, but it does not define new Subject DN, but rather a new extension that will be bound to the Subject. (I was surprised that RFC3779 was not in the SIDR WG's list of documents,but I guess it preceeded the SIDR working group, and occured in PKIX) In ANIMA's ACP document, we have an abomination that leverages rfc822Name, mostly because we figure the odds of getting anything else through off-the-shelf CAs is nil. Note to consumed with things in your stomach: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-20#section-6.1.2 Jakob Bohm via openssl-users wrote: > As the author of a proposal in this area, could you define a notation > for IPv6 DNs, perhaps one that actually reflects the hierarchical nature > of IPv6 addresses? RFC3779 does some of that, but not in the DN itself. > You could take inspiration from the (unfortunately rarely used) > hierarchical DN representation of DNS names (this used the DNS > specific DC name components). Overall the goal is to allow X.500 > distinguished name restrictions to work correctly. Yes, we could abuse the DC component. Were you thinking about: DC=2001/DC=0db8 > In practice you could follow the nibble notation as already used > for delegation of IPv6 reverse lookups in DNS. so more correctly: DC=2/DC=0/DC=0/DC=1/DC=d/DC=b/DC=8 > However for the CN in the end cert you could perhaps use the full > DNS reverse IPv6 name > "x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa" > or the URL/Mail notation "[:::::::]" > where the hex notation shall be the shortest form permitted by the > IPv6 notation spec. Bob, this seems like the best immediate hack to me. -- ] 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[ signature.asc Description: PGP signature
Re: ECDSA curves and certificates in 1.0.2X vs 1.1.x
Viktor Dukhovni wrote:
> On Tue, Jun 25, 2019 at 10:38:50AM -0400, Michael Richardson wrote:
>> openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
>> -nodes -subj "/CN=${ULA_HOSTNAME}" \
>> -keyout ${KEY_NAME}.key -out ${KEY_NAME}.csr -outform DER \
>> -reqexts SAN \
>> -config /tmp/shg.ossl.cnf
> This generates a key that has explicit parameters (rather than a named
> curve) also in OpenSSL 1.0.2h, for example. Since you probably want
> to use named curves, with 1.0.2 you'll have to generate the key
separately,
> and explicitly indicate that you want a named curve key. For that also
> include an additional:
> -pkeyopt ec_param_enc:named_curve
> option. This was not on by default in OpenSSL 1.0.2.
Thank you again, this worked great.
(I wonder if we had that before, and it just got lost as we rebuild from source)
--
] 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[
signature.asc
Description: PGP signature
ECDSA curves and certificates in 1.0.2X vs 1.1.x
The CIRALabs SecureHomeGateway generates an ECDSA key/CSR at manufacturing
time which is enrolled into a CA to form an IDevID certificate.
We are pondering a regression where the generated key goes clearly
prime256v1, and "prime-field". We are generating with
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
-nodes -subj "/CN=${ULA_HOSTNAME}" \
-keyout ${KEY_NAME}.key -out ${KEY_NAME}.csr -outform DER \
-reqexts SAN \
-config /tmp/shg.ossl.cnf
Evidence below, and also at:
https://gist.github.com/mcr/089fe7206644f417ba213c9dfe093c7a
I thought that maybe we had a build-regression that meant that we went from
1.1.x back to 1.0.x (this is with nic.cz's build of openwrt 18.06), but so
far this does not appear to be the case. But... it worked before! I swear.
(so I didn't think about the version that there)
***
My question is: is there some build options that I can't see that might have
affected this? Made it work before. My impression is that 1.0.x did *not*
support ECDSA certificates, yet it seemed to generate CSRs, just does not put
in the
right OIDs in the public parts such that it is recognized by others.
***
We happen to include 1.1.1 in a container, and I will probably change things
to use the openssl inside the container to generate the CSR, but I'm rather
confused.
1.1.1:
root@turris:/etc/shg# openssl ec -noout -text -in shg.key
read EC key
Private-Key: (256 bit)
priv:
stuff
pub:
04:0c:d5:2f:3b:ed:17:ae:dc:50:57:23:60:10:1e:
e3:61:84:3b:f4:ad:dd:0d:f4:cd:b4:81:f9:45:4c:
ee:aa:c6:d3:1a:0c:db:5d:4a:ad:fe:26:d7:c9:a8:
a2:3c:b6:97:4e:f0:bc:10:37:a2:cc:7b:9a:e6:40:
ea:c3:1d:d9:52
ASN1 OID: prime256v1
NIST CURVE: P-256
With an openssl 1.0.2s or 1.0.2l:
OpenSSL 1.0.2l 25 May 2017
read EC key
Private-Key: (256 bit)
priv:
stuff
pub:
04:c5:e6:dc:fc:df:c1:c0:c2:88:c0:b8:c2:dc:d0:
fa:1c:3a:84:1a:52:66:8c:fb:a1:bf:c9:77:e1:fa:
41:33:9a:33:2a:a8:73:ff:70:1b:3d:bb:d9:cf:a0:
bb:9f:78:14:37:3a:f8:55:bc:7a:86:a3:c2:66:ea:
b8:e9:3d:05:5d
Field Type: prime-field
Prime: ..elided
A:
B:
Generator (uncompressed):
Order:
Cofactor: 1 (0x1)
Seed:
--
] 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[
Re: TLSv12 Client Certificate Selection Behavior !!
Viktor Dukhovni wrote: > Yes, v1 certs would get a free ride. The reason to enforce KU > in client certs would be that client certs are not infrequently > (though not always) optional, and it can be better to not send > any client cert, than to send one the server will reject. 802.1AR seems to discourage KU in IDevID because at most KU bits make the certificate less useable, and IDevID certificates are expected to live for decades. > RSA client certs without digital signature in KU are increasingly > not interoperable as more server implementations are checking the > keyUsage these days. So at some point it makes sense to consider > not offering such (client) certs to the peer server. I would like knobs for this. -- ] 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[ signature.asc Description: PGP signature
Re: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1
Chethan Kumar wrote: > Sorry for the inconvenience caused by not asking query clearly. > Below is the output from ldd on application. Right, and now you need to recursively go through the list with readelf or ldd, and which out which one of these libraries then requires libcrypto.1.0.0. My bet is on some of the krb libraries, likely required by sqlite or perhaps something else like this libCryptolib.so.0. Also, run your application, and use "lsof -p PID" to see the list of libraries loaded as some dependancies may be done at runtime by dlopen(). -- ] 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[ signature.asc Description: PGP signature
Re: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1
In general, this occurs because you have some other libraries (from your system) that link against libcrypto.so.1.0.0. In theory, it should all just work, but in practice I've often found my application did not work as expected. Specifically, I'd get a TLS end point that did not speak ECDSA (1.0 does not, 1.1 does). You have make a pass through the shared objects that your application references (ldd output), and then using ldd, you can discover which ones want libcrypto.so.1.0.0, and then you either have to upgrade those libraries, or you may have to compile them from source. The last time I did this, I found it was libpqclient5 (a postgresql client library), and that I was able to upgrade it to libpqclient10 rather than resort to source code. Minimal distributions like containerized alpinelinux also help to minimize your dependancies. -- ] 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[ signature.asc Description: PGP signature
Re: creating certificate only structure -- CMS_sign
{resending, because it did not seem to make it into the archives}
https://www.openssl.org/docs/man1.1.0/man3/CMS_sign.html says:
If signcert and pkey are NULL then a certificates only CMS structure is
output.
I am trying to create one to return in an RFC7030 (EST) /cacerts request.
It appears that it needs to be a NID_pkcs7_signed.
a) Do I need to set any flags?
b) I assume that any certificates in the STACK_OF(X509) *certs will be included?
c) Does it have to have CMS_PARTIAL or some other flags set, and then call
CMS_final() explicitely?
I am getting
error:2E07F068:CMS routines:CMS_final:cms lib
(I think I am dumping the entire error stack with:
unsigned long err = ERR_get_error();
while(err != 0) {
fprintf(stderr, "error: %s\n", ERR_error_string(err, NULL));
err = ERR_get_error();
}
when called like:
signcert: (nil) pkey: (nil) certs: 0x563df7fc1e30 bio: (nil), flg: 0
(via ruby, I haven't written a C-only example yet...)
I am running with => "OpenSSL 1.1.1-dev xx XXX ", which is really
1.1.1c with a patch to the DTLS code.
Looking at CMS_dataInit(), it looks like if the contentType is not set,
and icont is NULL, and no content was provided into the CMS structure,
that it simply runs to the end and returns NULL. Or, it is type
pkcs7_signed, and since cont and icont are NULL, it also returns NULL.
If I had run into an error, there would be additional items on the error stack.
It appears that it needs to be a NID_pkcs7_signed, so it seems that returning
with no content is what is happening. I try adding some data to sign, but I
get the same error.
Looking at test/cmsapitest.c, I think that probably cert only payload
creation is simply not tested/implemented. Would I be wrong here?
I haven't looked at "openssl cms" to see if it can be built that way.
--
] 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[
signature.asc
Description: PGP signature
creating certificate only structure -- CMS_sign
https://www.openssl.org/docs/man1.1.0/man3/CMS_sign.html says:
If signcert and pkey are NULL then a certificates only CMS structure is
output.
I am trying to create one to return in an RFC7030 (EST) /cacerts request.
It appears that it needs to be a NID_pkcs7_signed.
a) Do I need to set any flags?
b) I assume that any certificates in the STACK_OF(X509) *certs will be included?
c) Does it have to have CMS_PARTIAL or some other flags set, and then call
CMS_final() explicitely?
I am getting
error:2E07F068:CMS routines:CMS_final:cms lib
(I think I am dumping the entire error stack with:
unsigned long err = ERR_get_error();
while(err != 0) {
fprintf(stderr, "error: %s\n", ERR_error_string(err, NULL));
err = ERR_get_error();
}
when called like:
signcert: (nil) pkey: (nil) certs: 0x563df7fc1e30 bio: (nil), flg: 0
(via ruby, I haven't written a C-only example yet...)
I am running with => "OpenSSL 1.1.1-dev xx XXX ", which is really
1.1.1c with a patch to the DTLS code.
Looking at CMS_dataInit(), it looks like if the contentType is not set,
and icont is NULL, and no content was provided into the CMS structure,
that it simply runs to the end and returns NULL. Or, it is type
pkcs7_signed, and since cont and icont are NULL, it also returns NULL.
If I had run into an error, there would be additional items on the error stack.
It appears that it needs to be a NID_pkcs7_signed, so it seems that returning
with no content is what is happening. I try adding some data to sign, but I
get the same error.
Looking at test/cmsapitest.c, I think that probably cert only payload
creation is simply not tested/implemented. Would I be wrong here?
I haven't looked at "openssl cms" to see if it can be built that way.
--
] 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[
signature.asc
Description: PGP signature
Re: configuring callbacks (or not) and SNI vs not... no shared cipher from server end
Viktor Dukhovni wrote: >> Diversionary issue: >> https://www.openssl.org/docs/manmaster/man3/SSL_set_tlsext_host_name.html >> and: >> https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_client_hello_cb.html >> >> are pretty vague. I think that SSL_set_tlsext_host_name() is probably >> intended to be used on the client to set the SNI, but I'm not sure. > Yes, e.g. in the Postfix TLS client: > https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1035-L1045 So, okay. Either this URL can go into the man page, or some short code extract could go in. >> The legacy cb function returns int, but it's values are not >> documented. > On the server side I'm using SSL_CTX_set_tlsext_servername_callback(): > https://github.com/vdukhovni/postfix/blob/2399e9e179ee025d03155fa3637cccab0a23ddce/postfix/src/tls/tls_misc.c#L1040-L1043 > https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_misc.c#L668 >> I guess the point is that CB can set the server certificate to >> something appropriate, or I think, it could just decide to ignore the >> SNI value completely and force the certificate regardless. > Yes. I can see that the CB provides comprehensive functionality, but I worry about applications trying to parse ClientHello extensions themselves and getting it wrong. >> What is the SNI functionality otherwise on the server? > You can interpose a secondary "virtual-host-specific" SSL_CTX for for > the rest of the handshake. This carries the server certificate, but > also the trust store settings for validating client certificates, the > settings to request (or not) client certificates, the verification > callbacks, ... It is a rather heavyweight object, best cached and > re-used for multiple connections. So, it's okay to change the SSL_CTX for an SSL* after creation. That is rather surprising to me, but I guess it's okay. I suppose I feel that there ought to be reference counts, but this is C, not Rust. > In Postfix, it is configured with the same settings as the initial > SSL_CTX, *but* no server certificates. During the SNI callback I > interpose the certificate-less context, and then set the certificate > chain on the connection handle (SSL *) instead. okay, I'll use Postfix as my reference :-) >> Is there any support for picking a certificate based upon the SNI >> name? > The application does the "picking"... The application sets one or more > certificate chains (one per supported public key algorithm) that best > match the SNI name, and then OpenSSL chooses one of these based on the > client's advertised supported signature algorithms, ... What I was observing (wrongly) was that maybe the server was doing something itself if there was no callback, and it was failing. This was from looking at the code around the error code that came out. This (see other email) proved to wildly incorrect. -- ] 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[ signature.asc Description: PGP signature
Re: configuring callbacks (or not) and SNI vs not... no shared cipher from server end
My questions about the documentation of the callbacks remain. Having solved the problem, I'm pretty certain the the "no shared cipher" error message is way too overloaded. Some piece of code is clearly doing something useful, which is to check if the public/private key match. Unfortunately, that code is not announcing the mismatch in a useful way. My provisioning script, due to a typo, was generating new CSRs, but sending an ancient CSR with an old public key. Writing up the problem, I eventually noticed the public key dump from the private key file did not match the dump from the certificate. -- ] 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[ signature.asc Description: PGP signature
configuring callbacks (or not) and SNI vs not... no shared cipher from server end
Diversionary issue:
https://www.openssl.org/docs/manmaster/man3/SSL_set_tlsext_host_name.html
and:
https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_client_hello_cb.html
are pretty vague. I think that SSL_set_tlsext_host_name() is probably
intended to be used on the client to set the SNI, but I'm not sure.
The legacy cb function returns int, but it's values are not documented.
The newer cb function is better documented, but I'm a bit at a loss as to
what SSL_client_hello_get0_ext() extracts. Is the CB expected to parse the
extensions itself?
I guess the point is that CB can set the server certificate to something
appropriate, or I think, it could just decide to ignore the SNI value
completely and force the certificate regardless.
What is the SNI functionality otherwise on the server?
Is there any support for picking a certificate based upon the SNI name?
EXEC SUMMARY
I am asking because I seem to have run into a situation where it does not
seem to do the right thing, but I'm not sure that the error that I'm getting
is really about selecting the right certificate, or if there is something
else going on. Well, I'm pretty sure that the "no shared cipher" (on server)
is wrong. This comes out stderr upon receipt/processing of ClientHello.
Things I have tried (described below):
1) making sure that I'm running 1.1.1, which has ECDSA support, and not
getting 1.0 shared object by mistake (this has happened before)
2) making sure that the SubjectName contains the target SNI.
(with working certificate, it does not matter to server if I use wrong name)
3) observed private key was in different (SEC1 vs PKCS8) format, tried
switching that.
Many details at: http://www.sandelman.ca/tmp/certprob201905/
A longer story
--
In testing of a rails-based HTTPS server I have typically just configured a
keypair without a lot of thought to the DN used for the server. As I have
some (experimental) patches to openssl and ruby-openssl, I often struggle
with having the wrong shared object pulled in and then some things do not
work. In particular, I would get a message about no shared cipher on the
server emitted when something linked in openssl 1.0.x rather than 1.1.x,
and I had configured an ECDSA keypair. I'm not sure if it was precisely:
140639813764864:error:1417A0C1:SSL routines:tls_post_process_client_hello:no
shared cipher:ssl/statem/statem_srvr.c:2131:
(1) which I'm now getting, but it was close to that. I seem to recall that the
file name mentioned was one that was in 1.0.x, but not in 1.1.x, which was
the clue that I had made a linking error. I got this again yesterday while
testing, and wondered if I could excise 1.0.x completely from my laptop, and
finally found that it was only an old version of libpq5 that linked against
it, and an upgrade (via postgresql.org debian package) eliminated my ruby
process from ever linking 1.0.x.
Yet the error persisted. I test with the hostname target of
"fountain-test.example.com", which I put into my /etc/hosts as ::2
(an alias on lo), and bind against.
The private keys are test keys, and I could share them if that was useful.
NOTE that both working and failing certificates are generated by ruby code.
(2) I went back to a known working situation where a locally generated
certificate with that name as the CN was present:
(file: http://www.sandelman.ca/tmp/certprob201905/working-cert.txt and .pem)
Issuer: DC = ca, DC = sandelman, CN = fountain-test.example.com\0A
Unstrung Fountain Root CA
Validity
Not Before: May 7 22:56:23 2019 GMT
Not After : Jun 7 08:56:23 2019 GMT
Subject: DC = ca, DC = sandelman, CN = fountain-test.example.com
And this one works regardless of what name I use to access it. That is,
given:
::2 fountain-test.sandelman.ca fountain-test.example.com
n3CE618.router.securehomegateway.ca
all three of:
%curl -k https://fountain-test.sandelman.ca:8443/version.json
{"version":"0.7","revision":"devel"}%
%curl -k https://n3CE618.router.securehomegateway.ca:8443/version.json
{"version":"0.7","revision":"devel"}%
%curl -k https://fountain-test.example.com:8443/version.json
{"version":"0.7","revision":"devel"}%
work. Using what I think is a similar certificate:
/corp/projects/shg/shg_mud_supervisor/spec/files/product/Smarkaklink-n3ce618/jrc_prime256v1.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 840664151 (0x321b8457)
Signature Algorithm: ecdsa-with-SHA256
Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN =
highway-test.example.com CA
Validity
Not Before: May 8 17:18:37 2019 GMT
Not After : Dec 31 00:00:00 2999 GMT
Subject: CN = n3CE618.router.securehomegateway.ca
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
Re: Listing TLS 1.3 Ciphers
Benjamin Kaduk via openssl-users wrote: >> Very odd. I thought that there were more at one point. > The ones with truncated (8-byte) authentication tag are not intended > for general use and don't make it into the default list. I think that those are the ones that constrained devices prefer, such as ECDHE-ECDSA-AES128-CCM8? So is there a way to validate that they are available, that there were compiled in? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature
Re: new algorithms
>> creation of x509 certificate with algo1 and algo2, and/or TLS and SSL >> connection always with algo1 and algo2 Tobias Nießen wrote: > As far as I know, you will need to have an OID assigned for each > algorithm for x509 certificates. You can add those to OpenSSL manually, > but you won't be able to communicate with any other software that does > not implement them. (And as Rich said, there is little reason for > people to trust and use non-standard algorithms.) But, if your goal is private testing of your stuff, then any OID will do, including one you allocate with a Private Enterprise Number, which you can get from IANA by filling out a simple form. You'll likely have to add the OIDs to the object.txt and run some scripts. -- ] 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[ signature.asc Description: PGP signature
Re: PKCS#7/CMS verify reports bad signature
Matt Caswell wrote: > 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: What had produced the signatures? > 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. > 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. Did openssl ever produce these wrong signatures? signature.asc Description: PGP signature
Re: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
Blumenthal, Uri - 0553 - MITLL wrote: > Hmm... Registering an OID dedicated to express this case should be > feasible, and perfectly within the ASN.1 rules. One question - where in > the OID tree would it live, as offhand I don't have any idea. It can't > be too deep down, and also, it better be fairly short. In some vendor PEN space if 0.0 is a bad idea. I'm sure that someone has one, or I can volunteer a number from mine. I don't see why it has to be short if it never leaves in a legitimate CSR. > From the ASN.1 point of view - there's nothing dumb in this > idea. There's plenty of MIB objects expressing/representing all kinds > of things - might as well add this. +1. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature
version mismatch macro help
Last year I tried to provide a macro that would do version checks. (In fact, I got it wrong in a stupid way) Today I installed a pre 1.1.1c build in a VM for testing purposes. What does /usr/sbin/sshd says: # /usr/sbin/sshd OpenSSL version mismatch. Built against 1010101f, you have 10101030 Clearly 10101030 >= 1010101f, and the major.minor version match, so there really shouldn't be an issue. But openssh seems to have got it wrong, as far as I can tell. I will submit a bug report soon. Can we include a useful macro/test for applications to deal with this consistently? -- ] 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[ signature.asc Description: PGP signature
Re: shared libraries vs test cases
Richard Levitte wrote: >> Running LDD on the binaries in test/* shows that they appear to link against >> the "system" copies of libssl and libcrypto. >> >> Perhaps something I'm missing is setting up LD_PRELOAD or some such so that >> the tests run the local copy of libssl/libcrypto, but I can't find that. >> Am I missing something? >> >> This is, I think, making it very difficult for me to bisect a problem. >> >> It seems to me that the test cases ought to be statically linked to make >> it easiest to know what code they are running. (This also makes it slightly >> easier to use gdb on them) > There's a script called util/shlib_wrap.sh that you place first on the > command line: > ./util/shlib_wrap.sh test/whatevertest > ./util/shlib_wrap.sh ldd test/whatevertest > ./util/shlib_wrap.sh gdb test/whatevertest And another email says that this is done by default for "make test". -- ] 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[ signature.asc Description: PGP signature
Re: OpenSSL 3.0 vs. SSL 3.0
Christian Heimes wrote: > I'm concerned about the version number of the upcoming major release of > OpenSSL. "OpenSSL 3.0" just sounds and looks way too close to "SSL 3.0". > It took us more than a decade to teach people that SSL 3.0 is bad and > should be avoided in favor of TLS. In my humble opinion, it's > problematic and confusing to use "OpenSSL 3.0" for the next major > version of OpenSSL and first release of OpenSSL with SSL 3.0 support. You make a good point which I had not thought about, having exhumed SSLx.y From my brain. +5 > You skipped version 2.0 for technical reasons, because (IIRC) 2.0 was > used / reserved for FIPS mode. May I suggest that you also skip 3.0 for > UX reasons and call the upcoming version "OpenSSL 4.0". That way you can > avoid any confusion with SSL 3.0. Integers are cheap. And 4.0 is > 3.0, so (Open)SSL 4.0.0 must be better than SSL3. -- ] 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[ signature.asc Description: PGP signature
shared libraries vs test cases
Running LDD on the binaries in test/* shows that they appear to link against the "system" copies of libssl and libcrypto. Perhaps something I'm missing is setting up LD_PRELOAD or some such so that the tests run the local copy of libssl/libcrypto, but I can't find that. Am I missing something? This is, I think, making it very difficult for me to bisect a problem. It seems to me that the test cases ought to be statically linked to make it easiest to know what code they are running. (This also makes it slightly easier to use gdb on them) -- ] 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[
Re: [openssl-project] OpenSSL 3.0 and FIPS Update
Not sure who Matt quoted, wrote: >> 2. Can we do something with a bunch of hard-linked non-extendable >> lists of internal NIDs? >> >> For example, providing GOST algorithms always requires a patch to >> extend 3-5 >> internal lists. >> If it could be done dynamically, it will be great. Matt then wrote: > The simplest solution is to submit a PR to add your OIDs to OpenSSL, > so that no furher out of tree patches are required. Viktor Dukhovni wrote: > Dynamic NIDs don't fit very well into the design, because NIDs are > expected to be stable compile-time constants. We could perhaps > reserve a range for "private-use", and "engines" could allocate new > NIDs in the private space at runtime. The key question is whether > such NIDs are global or valid only if returned to the same engine > (provider, ...). If not global, the allocation might be static > within the engine, and not require any locks. Having stubbed my toe on some NID stuff, I must question exposting NIDs. ruby-openssl used them in a dumb way that meant that adding extensions by OID was broken until I removed some code. I think that the #define/enum of NIDs should be made internal-only, available as optimization to internal code only. Your question then becomes, "are engines internal users", and I'd like the answer to be no. I think that the openssl 3 changes suggest the same thing. All other users can call OBJ_obj2nid() or OBJ_txt2nid() to get a NID, and we can figure out how to allocate things dynamically if this makes sense. I don't know which APIs are currently NID-only. -- ] 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[ signature.asc Description: PGP signature
Re: [openssl-users] [openssl-project] OpenSSL 3.0 and FIPS Update
Matt Caswell wrote: > Please see my blog post for an OpenSSL 3.0 and FIPS Update: > https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/ Thank you, it is very useful to have these plans made up front. I think your posts should probably explain what happened to 2.x, and if this represents a move towards semantic versioning. (I think it does...?) In the various things linked, in particular: https://www.openssl.org/docs/OpenSSL300Design.html I think that there is a missing box. Specifically, the PERL API wrappers that are used in the test bench. I believe that the "applications" are a serious problem as there are (in 1.1.1) still many things that are very difficult (sometimes, it seems, impossible) to do programmatically, and which the test cases actually simply shell out to the application to do. An example of this is adding certain extensions to a certificate when generating it, which is only really possible by loading pieces of configuration file in. So what I'd like to see is to remove many of the applications from the core of OpenSSL, put them into a seperate package using better-documented API calls. Let them evolve according their own time-scale, probably taking patches faster without disrupting the underlying libraries. My observation is that the Perl testing system is used to drive the tests, but the tests do not actually use the Perl API wrapper for OpenSSL, but rather rely on the vast number of .c files in test/*. In other (more purely agile) projects, the test cases often serve as documentation as to how to use the API. In OpenSSL, the test cases rely too much on the openssl "applications", and the API is hidden. This would involve adopting some or all of Net::SSLeay. While there would be some initial duplication of effort, I think that over time it would sort itself out. Perl is no longer as cool as it used to be (I still like it) and maybe someone would argue for Python3 or something, and frankly I don't care which. What I care about is that the test cases actually test the API, rather than depend upon 20 years of twisty code in the "applications". And that the applications are permitted to grow/change/adapt to people's needs, rather than living in a hard spot between developer needs and end user needs, pissing off both groups. -- ] 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[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] setting eContentType for CMS messages without CMS_PARTIAL
A major way in which PKCS7 and CMS signed artifacts differ is that the CMS artifacts include a content-type. RFC5652 has a decision tree to decide what version of SignedData structure to produce. The presence of a non-"id-data" content-type is among the decision tree, and so I understand why it can't be set after the signature (besides, the content-type is within the signature!). I think it's probably too complex that the only way to set the content-type is by doing the CMS_PARTIAL work. I think that CMS_sign() and CMS_encrypt() ought to take a eContentType OID: but ABI issues would mean a new call. I had to read the source code to understand the difference between CMS_get0_type() and CMS_get0_eContentType(). I can see how one refers to the cms->contentType, and the other refers to the same thing "as received", in the structure (RFC5652's EncapsulatedContentInfo). I'm not sure if there is intended to be functional or API contract differences between the two?? I was also mystified about get0_content(), until I realized that it did not have the word "type" in it. I've sent some pull requests, one of which suggests that you can't call get0_content() until CMS_final() has been called on outgoing objects. CMS_get0_content() returns a pointer to a pointer, and it says down at the bottom that it can be used to modify the content. It's clear that a receiver (verifier/decrypter) can mutate this content as part of it's processing: saves memory for a buffer, a copy, and a potential buffer overflow, I guess. It's unclear to me of what use this is for outgoing content. Clearly one could allocate an ASN1_OCTET_STRING big enough for constructing content, or point it at a buffer already in use. Clearly that's nonsense if CMS_PARTIAL is not used, and I wonder if CMS_get0_content() should return NULL if the signature is already done. -- ] 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[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] setting eContentType for CMS messages without CMS_PARTIAL
A major way in which PKCS7 and CMS signed artifacts differ is that the CMS artifacts include a content-type. RFC5652 has a decision tree to decide what version of SignedData structure to produce. The presence of a non-"id-data" content-type is among the decision tree, and so I understand why it can't be set after the signature (besides, the content-type is within the signature!). I think it's probably too complex that the only way to set the content-type is by doing the CMS_PARTIAL work. I think that CMS_sign() and CMS_encrypt() ought to take a eContentType OID: but ABI issues would mean a new call. I had to read the source code to understand the difference between CMS_get0_type() and CMS_get0_eContentType(). I can see how one refers to the cms->contentType, and the other refers to the same thing "as received", in the structure (RFC5652's EncapsulatedContentInfo). I'm not sure if there is intended to be functional or API contract differences between the two?? I was also mystified about get0_content(), until I realized that it did not have the word "type" in it. I've sent some pull requests, one of which suggests that you can't call get0_content() until CMS_final() has been called on outgoing objects. CMS_get0_content() returns a pointer to a pointer, and it says down at the bottom that it can be used to modify the content. It's clear that a receiver (verifier/decrypter) can mutate this content as part of it's processing: saves memory for a buffer, a copy, and a potential buffer overflow, I guess. It's unclear to me of what use this is for outgoing content. Clearly one could allocate an ASN1_OCTET_STRING big enough for constructing content, or point it at a buffer already in use. Clearly that's nonsense if CMS_PARTIAL is not used, and I wonder if CMS_get0_content() should return NULL if the signature is already done. -- ] 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[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 manuals
Dr. Matthias St. Pierre wrote:
>> Generally I find everything I need in the source tarball and after the
>> install is done everything anyone could want is installed on the
>> system. As for 'sidenav' that sounds like someone actually has to go
>> tweak stuff manually on some website. Sadly. Anyways, the source
>> tarballs have everything that is for certain. A lot of symlinks to be
>> sure.
>>
>> Dennis
> All supported manual page versions are publicly available from this
> site here. https://www.openssl.org/docs/manpages.html
The listings like:
https://www.openssl.org/docs/man1.1.1/man3/
are basically useless for navigation.
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)
--
] 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[
signature.asc
Description: PGP signature
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 manuals
J. J. Farrell wrote: > man1.1.1 looks OK to me, the pages all appear to be there. What is > missing is a link to 1.1.1 in the little Manpages list of links on the > right hand side of the page https://www.openssl.org/docs/man1.1.0/crypto/CMS_sign.html exists, but https://www.openssl.org/docs/man1.1.1/crypto/CMS_sign.html does not. There are other examples which I have come across. > On 27/12/2018 16:31, 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) > -- > J. J. Farrell Not speaking for Oracle > > Alternatives: > > -- > 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] openssl 1.1.1 manuals
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[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] moving from PKCS7 to CMS functions
I am implementing a module for ruby-openssl to add CMS API access to ruby. (Once I figure it out, I will likely look at how to refactor PKCS7 API code, but I don't care about that yet) PKCS7 has the PKCS7_SIGNER_INFO object, and it is declared in pkcs7.h with DECLARE_ASN1_FUNCTIONS(). CMS has the CMS_SignerInfo object, but it is not declared in cms.h, and so has no _alloc/_free API. Is this an oversight? Or is there a some difference in the API which I have yet to understand which would mean that CMS_SignerInfo objects would never be allocated/freed. (I found it surprising that DECLARE_ASN1_FUNCTIONS() was in the X509_dup.pod file) -- ] 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[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Subject CN and SANs
Salz, Rich via openssl-users wrote: > 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. Fair enough. It seems that the "openssl ca" mechanism still seem to want a subjectDN defined. Am I missing some mechanism that would let me omit all of that? Or is a patch needed to kill what seems like a current operational requirement? -- ] 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[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] does -subj suppress challenge Password prompt
From my colleague Peter.
Peter is attempting to generate a variety of CSR requests for use in
examples for an IETF ACE WG on coap-est.
Below my problem:
the standard openssl.cnf file is attached.
The openssl version is 1.0.1f.
When I do the following shell script:
countryName="/C=US"
stateOrProvinceName="/ST=CA"
localityName="/L=Oak Park"
organizationName="/O=Example Inc"
organizationalUnitName="/OU=Acme"
emailAddress="/emailAddress=p...@example.com"
commonName="/CN=Root CA"
DN=$countryName$stateOrProvinceName$localityName
DN=$DN$organizationName$organizationalUnitName$commonName
echo $DN
{ above from Bob's PKI document}
openssl req -config ./openssl.cnf \
-new -sha256 -key test.key -out test.csr
__
I get prompts for the subject names
Subject: C=au, ST=ddd, L=ddd, O=, OU=, CN=/emailAddress=a
and a prompt for challengePssword
When I change openssl command to:
openssl req -config ./openssl.cnf\
-subj "$DN"\
-new -sha256 -key test.key -out test.csr
no more prompts, but the challengePassword has disappeared from the
attibutes section.
How can I define the challengePassword while still using -subj
thanks for an answer,
Peter
--
Peter van der Stok
vanderstok consultancy
mailto: consulta...@vanderstok.org, stokc...@bbhmail.nl
www: www.vanderstok.org
tel NL: +31(0)492474673 F: +33(0)966015248
Below is his openssl.cnf:
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#
# This definition stops the following lines choking if HOME isn't
# defined.
HOME= .
RANDFILE= $ENV::HOME/.rnd
# Extra OBJECT IDENTIFIER info:
#oid_file = $ENV::HOME/.oid
oid_section = new_oids
# To use this configuration file with the "-extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions=
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)
[ new_oids ]
# We can add new OIDs in here for use by 'ca', 'req' and 'ts'.
# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6
# Policies used by the TSA examples.
tsa_policy1 = 1.2.3.4.1
tsa_policy2 = 1.2.3.4.5.6
tsa_policy3 = 1.2.3.4.5.7
[ ca ]
default_ca = CA_default# The default ca section
[ CA_default ]
dir = ./demoCA # Where everything is kept
certs = $dir/certs# Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database= $dir/index.txt# database index file.
#unique_subject = no# Set to 'no' to allow creation of
# several ctificates with same subject.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $dir/cacert.pem # The CA certificate
serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber# the current crl number
# must be commented out to leave a V1
CRL
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/cakey.pem# The private key
RANDFILE= $dir/private/.rand# private random number file
x509_extensions = usr_cert # The extentions to add to the cert
# Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt= ca_default# Subject Name options
cert_opt= ca_default# Certificate field options
# Extension copying option: use with caution.
# copy_extensions = copy
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crlnumber must also be commented out to leave a V1 CRL.
# crl_extensions= crl_ext
default_days= 365 # how long to certify for
default_crl_days= 30# how long before next CRL
default_md = default # use public key default MD
preserve= no# keep passed DN ordering
# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy = policy_match
# For the CA policy
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName= match
organizationalUnitName = optional
commonName = supplied
emailAddress= optional
# For the 'anything'
Re: [openssl-users] Multiple client connection to Nginx server
ASHIQUE CK wrote: > 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 You probably need to tell us: 1) which engine? did you write this engine? 2) whose driver? 3) what version of openssl? 4) what version of nginx? 5) how did you observe the problem you described? 6) is it different for, for instance, apache? or some other server software? > 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 ? > signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1.1 opaque structures
priya p wrote: > In openssl-1.1.1, few structures have been made opaque like HMAC_CTX, > EVP_CIPHER_CTX etc., > There are new API to get and set those structure members. But to > zeroize those structure members in place, I dont see any API. "in place", do you mean because you've allocated them as auto variables on the stack? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network 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
[openssl-users] understanding ASN1_item_verify()
Zero,
my goal is to validate Certificate Signing Requests in ruby.
First,
https://www.openssl.org/docs/man1.1.1/man3/ASN1_item_verify.html
and
https://www.openssl.org/docs/man1.1.0/man3/ASN1_item_verify.html
.. do not seem to exist, but at least
https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_asn1_set_ctrl.html
points to such a page.
I'm not sure what this means for this function. It also does not
show up in doc/*, but it is exported in crypto.num.
Maybe it should not be used by new code?
Second,
I was looking at:
int X509_REQ_verify(X509_REQ *a, EVP_PKEY *r)
{
return (ASN1_item_verify(ASN1_ITEM_rptr(X509_REQ_INFO),
>sig_alg, a->signature, >req_info,
r));
}
as I'm not sure that I want to build a ruby wrapper for X509_REQ.
I just don't understand ASN1_ITEM_rptr. My understanding is that
it returns a function (or global) that would be named X509_REQ_INFO_it().
But, how does the "a" argument get connected with this?
I'm thinking that there is some global "current ASN1 thing" that is involved,
but surely that can't be...
If there is any non-generic documentation on X509_REQ_*(), I haven't found it.
signature.asc
Description: PGP signature
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Backward compatibility for openSSL letter releases (openSSL 1.0.2 x)
Satish Lvr wrote: > Can we assume that backward compatibility would be maintained between letter > releases of a version such as openSSL 1.0.2 (Eg: between openSSL 1.0.2a and > openSSL 1.0.2p) unless there is security bug fix ? If one breaks backward (ABI) compatibility for a security bug fix, then the old code needs to be recompiled, so you can't fix the bug with an update to the .so. signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] updating openssl on MacOS
Salz, Rich via openssl-users wrote: > 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? that's what I had in mind. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] updating openssl on MacOS
(I'm a Linux desktop guy)
Sitting with a colleague, he's trying to get some code working that requires
ECDSA support, so openssl 1.1.0 or newer, and his Mac is infested with
0.98letter.
There are a a whole bunch of pages with a variety of recommendations.
None of them are on openssl.org... I wonder if openssl.org shouldn't
include at least a page of advice that is know to work?
My colleague eventually did something like:
brew update
brew uninstall --force openssl (unclear if this worked..)
brew uninstall --ignore-dependancies openssl
brew upgrade
brew install openssl
and the libraries wound up in /usr/local/opt/{include,lib}.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] X25519 - why openssl shows server temp key as 253 bits?
Robert Moskowitz wrote: > A curve point needs an x and a y. But do you need the y for the > computation. Do you only need its sign? I don't know. I am not a > mathematician. My understanding is that you need x and y to do the computation. (And I observe this in code) However, since x and y have to be on the curve, if you know x, then that constrained y to be one or two values... so you need to know the *sign* of y, which is transmitted as a single bit. Then you can calculate y. The fundamental reason behind this is because sqrt(4) = 2, and sqrt(4) = -2... Since some bits of the x are required to be 0, it's possible to encode the sign of Y into the encoded X bit-stream... -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Multi client DTLS server on OpenSSL 1.1.x broken?
Philip Prindeville wrote: > You can create an SSL context and then bind a connection listener to > it. > If the library doesn’t specifically handle the case of DTLS (I know it > handles SSL and TLS), then it shouldn’t be too hard to cobble something > together and even get it upstreamed. Philip, DTLS is not just TLS over UDP. There is more to it that that. we are trying to do EXACTLY this, and we can't because the behaviour of DTLSv1_listen() does not let a library do this. And we can't open code actually, because it (DTLSv1_listen) uses APIs internal to libssl. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] TLS 1.3 and the release
PGNet Dev wrote: >> I'm just dealing with trying to get openssl 1.1.0 to get installed on Ubuntu >> bionic. Yes, there is a package, but all the other packages depend upon >> 1.0.x and many things are linking against 1.0.x rather than 1.1, when >> both are installed... I don't know why they build stuff against 1.0.x >> rather than 1.1.0: I think it's a packaging oops. > In the "I'm guessing this is NOT news to anyone HERE" category No kidding. If we want to push making TLS available 1.3, then we need to do some remedial work where. > Even the packages that DO 'build against' 1.1.0 frequently do so by banking > on deprecated symbols made possible by lazy (imo) api-compat usage. I found that libssl-dev was not upgraded from 1.0.0 version to 1.1.0 version when I did the dist-upgrade. Once I flushed that, I could then rebuild things like ruby (and it's openssl module) against 1.1.0 correctly, and *THEN* re-install libssl1.0 to make openssh happy. > Packagers are frequently NOT cleaning up their openssl version-check logic, > and cleaning out old-/deprecated- symbols. In my experience, most seem not > to be interested, either; instead, the response mantra to entreaties about > clean/modern "--api=1.1.0" compatibility is "that's not what the distros > provide; just use that". +1. signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] TLS 1.3 and the release
Salz, Rich via openssl-users wrote: > You probably know by now that TLS 1.3 was just released as RFC 8446; > https://www.rfc-editor.org/info/rfc8446 This note is just trying to > forestall a number of question threads. > Our release plan called for one final beta (there were various > draft-interop things to take out and some other little nits) and then > the official release. We have had no discussion of changing that plan. SUPER DUPER There are a bunch of non-openssl-project issues that are gonna need some coordination if we are gonna get TLS 1.3 out there better. I'm just dealing with trying to get openssl 1.1.0 to get installed on Ubuntu bionic. Yes, there is a package, but all the other packages depend upon 1.0.x and many things are linking against 1.0.x rather than 1.1, when both are installed... I don't know why they build stuff against 1.0.x rather than 1.1.0: I think it's a packaging oops. The story is worse for Xenial, on which many containers are presently based. Debian jessie/stretch and Devuan jessie/ascii might be in better situation, or maybe my observations of them are tainted by having installed from source. I realize that this is "not your problem", but I want to suggest that we open an Issue now in order to attract google hits so that it can be coordinated. In particular there are dozens of ubuntu PPAs that have rebuilds of openssl + XYZ, but 3/4 of them are stale... it would be nice to nominate a non-lame "winner" I can open such an Issue if you like. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] RFC5077 ticket construction help
Henderson, Karl via openssl-users <openssl-users@openssl.org> wrote: > A wants to talk to B > A and B have a relationship with C > C constructs an RFC5077 ticket and gives it to A so that A can contact B > Are there any good examples of how to do this? Aside Viktor's comment, this is also classic OAUTH2 situation. But, it sounds like you need to do this below the application layer in the TLS layer. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network 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] Enable the FIPS mode in the library level
Dr. Matthias St. Pierre <matthias.st.pie...@ncp-e.com> wrote: > On 05.03.2018 10:46, Alan Dean wrote: >> Question 1: Is it even feasible to make the FIPS mode always enabled >> for the whole OpenSSL library (i.e. for both libcrypto and libssl), so > The optimal location for inserting the FIPS_mode_set(1) call is probably > OPENSSL_init() (openssl-1.0.2/crypto/o_fips.c), see code snippet below. > void OPENSSL_init(void) ... > However, I am sceptical whether this approach will be accepted, because > there are (at least) two potential problems: > * Normally, it is mandatory to check the result of FIPS_mode_set() or > FIPS_mode() to ensure that the FIPS initialization succeeded. However, > an application which is not FIPS-aware won't check the result. I think that Mr. Dean should check FIPS_mode_set() in OPENSSL_Init(), and should probably do something like core dump if it fails to turn on properly. Perhaps his system has a better way to get attention. > * It can happen that applications which have their own configuration and > enable/disable FIPS mode explicitely, call FIPS_mode_set(0) afterwards. That should probably also cause a core dump. Dr. Matthias St. Pierre <matthias.st.pie...@ncp-e.com> wrote: > One more obstacle: In FIPS mode it is not allowed to use low level > crypto algorithms, only the EVP interface is allowed. So most of your > non-fips-aware applications will malfunction when forced into FIPS mode. > The consequence is: it's probably not possible to do it. That should also cause a core dump. At the end, Mr. Dean will have a much reduced list of applications that he needs to either fix (sending patches upstream), or replace. And the core dumps will point directly into the application code that made the calls. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] DTLS server records repeated
I'm capturing from my DTLS client and server, with CoAP running on top. I've been debugging some ruby-level I/O buffering issues. I noticed this while capturing, and used tshark to get this print out. (I've added columns for port numbers) 2 66.009171 ::2 35345 ::2 5684 DTLSv1.0 263 Client Hello 3 66.009494 ::2 5684 ::2 35345 DTLSv1.0 122 Hello Verify Request 4 66.009798 ::2 35345 ::2 5684 DTLSv1.0 295 Client Hello 5 66.011771 ::2 5684 ::2 35345 DTLSv1.2 810 Server Hello, Certificate, Server Key Exchange[Malformed Packet] The Hello/Verify/Hello makes complete sense. tshark claims there is a malformed packet, but it seems to be the opinion of wireshark/tshark 1.12.1, as 2.2.6 (on my desktop vs laptop) has no problem with the packet. But, why are the Server Hello, Certificate and ServerKeyExchange then repeated in another three packets? The sequence numbers in the DTLS header seem to increment as well. It's like some PMTU detector is getting confused and trying to send again. 6 67.037421 ::2 5684 ::2 35345 DTLSv1.2 148 Server Hello 7 67.037453 ::2 5684 ::2 35345 DTLSv1.2 562 Certificate 8 67.037468 ::2 5684 ::2 35345 DTLSv1.2 199 Server Key Exchange[Malformed Packet] And then things proceed, apparently just fine. 9 67.037482 ::2 5684 ::2 35345 DTLSv1.2 87 Server Hello Done 10 67.037518 ::2 35345 ::2 5684 DTLSv1.0 295 Client Hello 11 67.041860 ::2 35345 ::2 5684 DTLSv1.2 195 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 12 67.044257 ::2 5684 ::2 35345 DTLSv1.2 328 New Session Ticket, Change Cipher Spec, Encrypted Handshake Message 13 67.044909 ::2 35345 ::2 5684 DTLSv1.2 135 Application Data 14 67.056746 ::2 5684 ::2 35345 DTLSv1.2 111 Application Data http://junk.sandelman.ca/junk/dtls1.pcap if you want to see more details. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] DTLS over UDP
Nivedita <maddi.nived...@gmail.com> wrote: >> Nivedita <maddi.nived...@gmail.com> wrote: >>> I am trying to establish DTLS over UDP connection by using >>> DTLSv1_listen method . >>> I have followed the below steps - 1. Created a server socket >>> and using >>> this socket created bio and ssl object. bio = >>> BIO_new_dgram(VI_sock,BIO_NOCLOSE)) SSL_set_bio >>> (ssl,VP_bio,VP_bio); >>> 2. Enable cookie exchange on SSL object. SSL_set_options(ssl, >>> SSL_OP_COOKIE_EXCHANGE); >>> 3. Then started listening using dtlsv1_listen for the new >>> client >>> connections. Once dtlsv1_listen is successful and i got the >>> peer >>> address. mcr> okay. >> Nivedita- All the above mentioned steps i am doing on server >> side . On the >> client side i have already initiated ssl_connect. >> On the server side when i am listening using dtlsv1_listen >> method - >>> 4. Once i got the peer address , i am creating one more socket >>> 5. With the new socket i tried to connect to peer address. > Then once i got the client address from the dtlsv1_listen method, > i am creating one more socket and trying to connect to this client > address. I think that I see what is wrong with your flow... you haven't taken the packet off the original socket, so SSL_accept is still looking for it. The flow is supposed to be: 1) client sends ClientHello 2) DTLSv1_listen() sees it, and sends a HelloVerifyRequest (I assume you have filled in the cookie callbacks. I think that perhaps there should be good cryptographic defaults available in the library. Maybe there are, and I'm ignorant of them) 3) Client sends ClientHello w/cookie. DTLSv1_listen() then sees that and tweaks the SSL* to indicate that the cookie has been accepted. Note that the packet is *LEFT* on the incoming socket so that SSL_accept() can process it. This is one the places where the DTLSv1_listen() API is rather hard to use in my opinion. 4) You make up new sockets, etc. 5) But, you need to call SSL_accept() once with the **old socket** to process packet that listen() left on it, and then you can switch the FD over! Of course, you probably want to make sure that SSL_accept() sends the reply correctly. What I do in my proposed DTLSv1_accept() API is that I move the data From the incoming socket to the new BIO's incoming queue: https://github.com/mcr/openssl/blob/dtls-listen-refactor/ssl/d1_lib.c#L964 /* At this point, there is a real ClientHello in serv->init_buf */ memcpy(rb->buf, serv->init_buf->data, serv->init_num); rb->offset = 0; rb->left = serv->init_num; and then remove the packet from the incoming socket. The situation is then returned like this so that the new sockets can be setup, but the incoming SSL_accept() BIO is stuffed with the correct (cookie-full) ClientHello, and replies will go to the right place with the right source address. I hope to get these patches accepted for the March 11 freeze, but you might not want to depend upon it. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Issue with select after SSL_get_wfd
Grace Priscilla Jero <grace.prisci...@gmail.com> wrote: > Thankyou Hugh, I know that it is datagram and we are not > acknowledged. I just was looking for a way if SSL will be aware whether > the packet is consumed or not. or anyway we can get the status from > SSL on the packet consumption. Yes, that's because you are trying to figure out if the socket has data on it that SSL needs so that you can switch to the correct SSL* for the next processing. That's why trying to do it all with one socket is a problem. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] DTLS over UDP
Nivedita <maddi.nived...@gmail.com> wrote: > I am trying to establish DTLS over UDP connection by using > DTLSv1_listen method . > I have followed the below steps - 1. Created a server socket and using > this socket created bio and ssl object. bio = > BIO_new_dgram(VI_sock,BIO_NOCLOSE)) SSL_set_bio(ssl,VP_bio,VP_bio); > 2. Enable cookie exchange on SSL object. SSL_set_options(ssl, > SSL_OP_COOKIE_EXCHANGE); > 3. Then started listening using dtlsv1_listen for the new client > connections. Once dtlsv1_listen is successful and i got the peer > address. okay. > 4. Once i got the peer address , i am creating one more socket > 5. With the new socket i tried to connect to peer address. Do you mean, you call "SSL_connect()"? Or do you mean you bind(2) and connect(2) the socket. > 6. Then i am trying to do ssl_accept on the new socket by calling > bio_set_fd. > BIO_set_fd(SSL_get_rbio(ssl),VI_new_sock_id,BIO_NOCLOSE); > BIO_ctrl(SSL_get_rbio(VP_ssl),BIO_CTRL_DGRAM_SET_CONNECTED, 0, > _addr); > SSL_set_fd(ssl,VI_newsock_id); So, SSL_set_fd() will allocate a ne bio, which probably undoes the effect of calling BIO_CRTL_DGRAM_SET_CONNECTED. Since you have set the fd of the existing BIO, I think you can omit that line. > VI_res = SSL_accept(ssl); > But ssl_accept will always return error code 2 [ i.e want read or want > write] > But if i am doing ssl_accept without doing the step no 6 it it will be > successful. Yes. > Could someone please let us know how to switch to newly created socket, > so that it can start using newly created socket for further read and > write operations and original server socket will keep on listening for > new connections. Do you expect additional connections on the existing socket? I've been working on some new API to make this all easier. Your method may fail if you have bound your "listen" to :: (0.0.0.0), and you have multiple IPs. In my case, I expect connections over IPv6 LL addresses, and there are always multiple of those, and ifindex issues as well. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OPENSSL_USE_IPV6 -- bio_dgram, vs travis-ci
Richard Levitte <levi...@openssl.org> wrote:
> It's defined to be 0 or 1 in include/internal/sockets.h, here are the
> relevant lines:
yeah, my eyes missed that in the grep output.
I saw no place in Configurations/ where it was either set or not set.
mcr> https://github.com/travis-ci/travis-ci/issues/3302
mcr>
mcr> You can't even bind ::1 on travis. I hate this jurassic stuff.
> OK, so here's another possibility... if you don't want to use IPv6,
> then don't use it! From an OpenSSL perspective, there are many
Uhm. The point is that my regression test will fail on travis-ci if I try to
test the IPv6 pathways, because you can't bind even ::1 on Travis-ci.
I've done a different hack which is probably equally stupid, which is to put
- TRAVISCI_NO_IPV6=true
into .travis.yml and test for it in the regression test. At least that means
that travis will *compile* the code, and we'll know if the IPv6 code fails to
compile at some point, even if we can't run it on travis.
{I should probably have made this a github issue... but... web browsers...}
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OPENSSL_USE_IPV6 -- bio_dgram, vs travis-ci
bio_dgram has a bunch of #if on: OPENSSL_USE_IPV6, and I thought that this might be a common #ifdef, but actually it only occurs in that file. I looked through Configurations, and I didn't see it at all. Other usage is #ifdef AF_INET6, but IPv6 code is available, but I want to build without it. Fundamentally, I want to turn off IPv6 testing off on travis builds, because travis has IPv6 turned off, see: https://github.com/travis-ci/travis-ci/issues/4964 https://github.com/travis-ci/travis-ci/issues/3302 You can't even bind ::1 on travis. I hate this jurassic stuff. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Information to detach a BIO from fd
Grace Priscilla Jero <grace.prisci...@gmail.com> wrote: > Below is our scenario on DTLS. > We have multiple connections to the same server. We have mapped one fd > to the ssl in the server to receive all connections. Are these connections from the same client (same 5-tuple), or are you just talking about multiple clients? > Whenever a connect is initiated from any client we need to know if it > is already connected client or a new client. We are doing this by > * creating bio/ssl each time on the same fd > * fetching the peer using BIO_dgram_get_peer after ssl_accept > * Comparing it to the internally maintained list of peer > * If it is a new peer we continue with handshake but if it is old peer > we do the ssl_read. I don't think this is going to work. A UDP/DTLS server has two choices: 1) read all the packets on a unconnected socket and demultiplex them into appropriate BIOs/SSL structures. I did not find an obvious way to do this, I think that a new BIO type would make this easiest. It also has the downside that it's hard to spread the load across multiple processes, although with the right locking multiple threads would likely work. 2) after each call to DTLSv1_listen(), set up a new fd that is bind()/connect()ed to the peer (by 5-tuple) so that all traffic from that peer arrives on the correct FD. AFAIK, there isn't anything to forbid two DTLS sessions between identical UDP sockets, as they could have differing session cookies, etc. > The problem is that there are 2 bio/ssl that gets created for the same > fd and the peer end up writing to one of them and we don't get the > message on the intended ssl. Hence we are checking for a way to detach > and remove the ssl/bio that gets created in already connected case. I don't think that is going to work. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fwd: Information to detach a BIO from fd
Priscilla Hero <grace.prisci...@gmail.com> wrote: > Hi Michael, Without doing ssl_accept on the ssl will getpeername work? ssl_accept() processes the packets on the socket. getpeername() on a (Unix) socket will always work. However, getpeername() on a UDP socket won't produce anything unless the socket was connect(2)'ed. In order to get the address of the remote system one has to get it when receiving the packet. That's why: https://github.com/mcr/openssl/commit/f764151782b4b32a752b4016336c0ceafa98ed5c retrieves the peer name from the BIO. > On 12-Jan-2018, at 6:45 PM, Michael Wojcik > <michael.woj...@microfocus.com> wrote: >> Don't create the BIO immediately. Use getpeername on the socket >> descriptor and check that against the list. Only create a new SSL >> object and BIO if it's not an already-established client. That only works with TCP. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fwd: Information to detach a BIO from fd
J Decker <d3c...@gmail.com> wrote: > I'm not 100% sure what you're doing I'd imagine that if SSL was > managing the fd's you wouldn't have this issue. You hvae to call > accept() to get a new FD... and you'll only get that once, so when you > accept() you should attach the bio and call ssl_accept(), no? accept(2) applies to TCP sockets only. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Information to detach a BIO from fd
Grace Priscilla Jero <grace.prisci...@gmail.com> wrote: > We are having a scenario wherein we are having 2 BIOs for DTLS > attached to the same fd. Each BIO has a different SSL associated with > it. The messages are getting written to different BIO each time and we > are trying to resolve it. > Is there a API or any way to detach one of the BIO/SSL from the fd for > DTLS? No. How did you get into that situation in the first place? My belief is that the DTLS API is suitable for (Secure)RTP only, and not for CoAP-type usage. (or other DTLS server end-point usage) According to some source code comments, you should have called connect() on the socket after the first connection was received, and then (or previously... there are race conditions either way), opened a new socket. I ran into this, and I wound up creating a new API, which is in a pull request: https://github.com/openssl/openssl/pull/5024 https://github.com/mcr/openssl/tree/dtls-listen-refactor Sadly, the new test case I wrote is not running consistently, which I'm still debugging. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Binding the socket to a source IP address before connect
Sanjaya Joshi <joshi.sanj...@gmail.com> wrote: > Is there a BIO family of API that OpenSSL provides to bind to a > specific source IP address before creating a socket connection (using > for e.g. BIO_new_connect()) ? I think not... BIO_new_connect() allocates the BIO, and so there isn't any state to set up before you call that. I've had to add a place to store the sockaddr to the DGRAM method in order to make DTLS work the way I want it, and it could be extended to TCP sockets I think, but not using the flow that you are using. However, you can provide the FD to the SSL context using BIO_set_fd() and SSL_set_bio(): BIO_set_fd(inbio, connectedfd, BIO_NOCLOSE); SSL_set_bio(ssl, inbio, outbio); Then you can set up the connectedfd any way you want, calling bind() before connect. That means that you might have to parse the host/IP + port yourself, but getaddrinfo() can do that for you, and int BIO_lookup(const char *host, const char *service, enum BIO_lookup_type lookup_type, int family, int socktype, BIO_ADDRINFO **res); wraps it all nicely for you. > My application does not need to rely on the kernel-provided source IP > address and hence the need for this. Just remember to test with IPv6 Link-Local addresses, because they do matter, and they are hard to get right from userspace. (And if you aren't doing IPv6 testing, then you probably shouldn't be creating new code) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Evaluation of OpenSSL stack software
Jan Graczyk <j.grac...@telic.de> wrote: > I am actually evaluating OpenSSL stack software to be possibly used in > my company next generation products. We would like to have a secure > connection between our device TCP/IP stack and web server which already > has SSL server running. I am looking for a benchmarks of OpenSSL client > running on ARM Cortex-M3 based processor. I would appreciate very much > feedback from you. Thank you. I think you'll need to be far specific. If you want to know bulk AES128 performance, then maybe this will help: https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/presentations/session7-vincent.pdf What compiler? What MHZ? What kind of RAM? The above paper uses mbedTLS (which used to be PolarSSL, but ARM bought it). The bulk rates are likely comparable. I don't have any data, but a google searched found a variety of papers. Fitting openssl into an M3's code space can be easy or hard depending on many factors. If you are concerned about setup times, then what method are you using to authenticate? (RSA? ECDSA? PSK? Raw Public Key) > Best Regards > Jan Graczyk > Embedded Software Developer – Embedded Software Poland > -- > Tel: +48 535 045 515 Telic AG cid:imag > Tel2: +49-89-673460-635 Raiffeisenallee 12b > E-Mail: j.graczyk@telic.de82041 Oberhaching > Web: www.telic.de Germany cid:image003.png@01D2336E.70B45010 > -- -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
