src: remove OCB support when OPENSSL_NO_OCB is defined #23635

codebytere · 2018-10-13T03:23:40Z

This PR places OCB-related code under a OPENSSL_NO_OCB flag.

In Electron, we use BoringSSL instead of OpenSSL as a result of Chromium, and BoringSSL isn't licensed to use OCB. This PR improves support for BoringSSL without changing any default behaviors.

/cc @tniessen @nornagon

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
commit message follows commit guidelines

nodejs-github-bot · 2018-10-13T03:23:41Z

@codebytere build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/1222/pipeline

davidben · 2018-10-13T03:42:54Z

Just came across this idly. You know we could just define the EVP_CIPH_OCB_MODE constant unused in BoringSSL. That's the sort of thing we normally do to avoid too many unnecessary ifdefs in the world.

tniessen · 2018-10-13T04:46:17Z

src/node_crypto.cc

-  if (mode == EVP_CIPH_CCM_MODE || mode == EVP_CIPH_OCB_MODE) {
+  bool needs_auth_tag_length = mode == EVP_CIPH_CCM_MODE;
+#ifndef OPENSSL_NO_OCB
+  needs_auth_tag_length |= mode == EVP_CIPH_OCB_MODE;


Some people won't be happy about using this operator I guess.

I guess the alternative would be something like

bool needs_auth_tag_length = mode == EVP_CIPH_CCM_MODE #ifndef OPENSSL_NO_OCB || mode == EVP_CIPH_OCB_MODE; #endif ;

? Not that much prettier ;)

I am fine with the change as it is, but other collaborators have expressed concerns about mixing int/bool operators in the past :)

I don't care about the operator mixing, but I very mildly prefer @addaleax's idiom above, and would use something similar to it for the block around line 2547 as well: a list of || blah statements, some of them with ifdef's around them.

addaleax · 2018-10-13T04:49:08Z

src/node_crypto.cc

-  if (mode == EVP_CIPH_CCM_MODE || mode == EVP_CIPH_OCB_MODE) {
+  bool needs_auth_tag_length = mode == EVP_CIPH_CCM_MODE;
+#ifndef OPENSSL_NO_OCB
+  needs_auth_tag_length |= mode == EVP_CIPH_OCB_MODE;


I guess the alternative would be something like

bool needs_auth_tag_length = mode == EVP_CIPH_CCM_MODE #ifndef OPENSSL_NO_OCB || mode == EVP_CIPH_OCB_MODE; #endif ;

? Not that much prettier ;)

src/node_crypto.cc

addaleax · 2018-10-13T20:25:34Z

CI: https://ci.nodejs.org/job/node-test-pull-request/17828/

addaleax · 2018-10-13T22:11:03Z

src/node_crypto.cc

+#ifndef OPENSSL_NO_OCB
+    || mode == EVP_CIPH_OCB_MODE
+#endif
+    ); // NOLINT


Looks like the Windows compiler is confused by this in some way…?

16:44:06 src\node_crypto.cc(2899): error C2121: '#': invalid character: possibly the result of a macro expansion [c:\workspace\node-compile-windows\node_lib.vcxproj]
16:44:06 src\node_crypto.cc(2899): error C2146: syntax error: missing ')' before identifier 'ifndef' [c:\workspace\node-compile-windows\node_lib.vcxproj]
16:44:06 src\node_crypto.cc(2899): error C2143: syntax error: missing ';' before '{' [c:\workspace\node-compile-windows\node_lib.vcxproj]

sam-github · 2018-10-13T22:49:40Z

Could we just defined EVP_CIPH_OCB_MODE to some unused value if there is no OCB? I assume attempts to use OCB would still fail later in the code path, but it would minimize the changes. I think @davidben was suggesting something like this, but in the boring ssl headers. We could do it locally, too:

#ifndef EVP_CIPH_OCB_MODE
#define EVP_CIPH_OCB_MODE 0x10003
#endif

If not, would it make sense for the ifdefs be on the existence of EVP_CIPH_OCB_MODE instead of the OPENSSL_NO_OCB so as to test directly for what we care about and not assume a relationship between the two macros that isn't necessarily going to be true with other openssl-alike crypto libs.

tniessen · 2018-10-13T23:12:25Z

The reason I told Shelley I would like to see this in core is that you can actually build OpenSSL without support for OCB, and OpenSSL relies on OPENSSL_NO_OCB, so this is not limited to BoringSSL.

node/deps/openssl/openssl/crypto/evp/c_allc.c

Lines 134 to 136 in fc0da7f

    
           #ifndef OPENSSL_NO_OCB 
        
               EVP_add_cipher(EVP_aes_128_ocb()); 
        
           #endif

We can still take @sam-github's approach as long as the actual behavior matches the expected behavior (which is that createCipher / createCipheriv fails with "unknown cipher").

mscdex · 2018-10-14T04:51:18Z

src/node_crypto.cc

@@ -2542,9 +2542,12 @@ int VerifyCallback(int preverify_ok, X509_STORE_CTX* ctx) {
 }

 static bool IsSupportedAuthenticatedMode(int mode) {
+#ifndef OPENSSL_NO_OCB
+  if (mode == EVP_CIPH_OCB_MODE)
+    return true;


This doesn't seem right. If there is no OCB support, we should not be returning true for OCB in a function that determines supported authenticated modes.

Also, I think we should replace this conditional with the same ifdef solution used in the other changes below for consistency.

#ifndef OPENSSL_NO_OCB implies that there is support for OCB, so this should be correct.

mscdex · 2018-10-14T13:50:24Z

I think we should be failing as early as possible when OCB is not available and someone tries to use it (directly or indirectly).

tniessen · 2018-10-14T21:28:34Z

I think we should go for consistency. How about this?

#ifdef OPENSSL_NO_OCB
# define IS_OCB_MODE(mode) false
#else
# define IS_OCB_MODE(mode) ((mode) == EVP_CIPH_OCB_MODE)
#endif

In my opinion, that's the cleanest solution, and I think that addresses all other review comments.

davidben · 2018-10-14T21:40:48Z

FYI, I've uploaded https://boringssl-review.googlesource.com/c/boringssl/+/32464 to BoringSSL. (Note OpenSSL normally defines EVP_CIPH_OCB_MODE even if you build with OCB disabled.)

sam-github · 2018-10-15T16:35:23Z

src/node_crypto.cc

@@ -2769,7 +2774,7 @@ bool CipherBase::InitAuthenticated(const char* cipher_type, int iv_len,
  }

  const int mode = EVP_CIPHER_CTX_mode(ctx_.get());
-  if (mode == EVP_CIPH_CCM_MODE || mode == EVP_CIPH_OCB_MODE) {
+  if (mode == EVP_CIPH_CCM_MODE ||IS_OCB_MODE(mode)) {


I think this will result in an odd behaviour. When attempting to use authenticated ciphers, there are certain arguments that are mandatory. Here, its the authTagLength that is checked for. If you don't provide it, this code will throw an error so you know you are calling the API incorrectly. With your change, if the OCB cipher mode isn't supported, it doesn't check for invalid API calls, and instead will (I assume) fail later, when the cipher runs, do to an unsupported cipher mode.

This doesn't seem ideal to me. It seems more reasonable to define EVP_CIPH_OCB_MODE correctly if it happens to be missing, and throw here. Of course, once they correct the code, it will still error, but later.

will (I assume) fail later, when the cipher runs, do to an unsupported cipher mode.

Not quite. You cannot construct an OCB cipher if OpenSSL does not support it: The mode can only be determined if the EVP_CIPHER* is known. Since EVP_get_cipherbyname(cipher_type) will fail for unsupported modes, InitAuthenticated is never called.

sam-github · 2018-10-15T16:36:28Z

src/node_crypto.cc

@@ -2544,7 +2549,7 @@ int VerifyCallback(int preverify_ok, X509_STORE_CTX* ctx) {
 static bool IsSupportedAuthenticatedMode(int mode) {
  return mode == EVP_CIPH_CCM_MODE ||
         mode == EVP_CIPH_GCM_MODE ||
-         mode == EVP_CIPH_OCB_MODE;
+         IS_OCB_MODE(mode);


The same comment as below applies here. IsSupportedAuthenticatedMode() is used to check for invalid API use. With this change, when the mode is not implemented by the crypto library, the checking for invalid or missing IV lengths done by CipherBase::InitIv() will be bypassed.

sam-github · 2018-10-15T16:41:28Z

@davidben why not set the defines to the same values as in openssl, so that they are unique? If someone is using the defines in a case statement, having them all be the same value could go awry.

tniessen

Still LGTM, thanks for following up on my suggestion @codebytere.

tniessen · 2018-10-15T16:54:54Z

CI: https://ci.nodejs.org/job/node-test-pull-request/17870/
Resumed in https://ci.nodejs.org/job/node-test-pull-request/17874/

davidben · 2018-10-16T16:01:21Z

@davidben why not set the defines to the same values as in openssl, so that they are unique? If someone is using the defines in a case statement, having them all be the same value could go awry.

No one seems to have used switch statements so far, but good point. :-) Switched them to distinct negative numbers.

I didn't match upstream's values because ours already don't match. Notably our current EVP_CIPH_MODE_MASK (0x3f) puts the bits all at the bottom whereas upstream is ABI-stable, so when they needed more mode bits, they took some upper ones (0xf0007). (If it turns out we need to match later, we can always go back and change that, but we don't generally want code to depend on exact values on constants.)

Node references it these days. Also replace the no-op modes with negative numbers rather than zero. Stream ciphers like RC4 report a "mode" of zero, so code comparing the mode to a dummy value will get confused. (I came across nodejs/node#23635, though we'd have run into it sooner or later anyway. Better to just define the value and avoid ifdef proliferation.) Change-Id: I223f25663e138480ad83f35aa16f5218f1425563 Reviewed-on: https://boringssl-review.googlesource.com/c/32464 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: Adam Langley <[email protected]> CQ-Verified: CQ bot account: [email protected] <[email protected]>

tniessen · 2018-10-16T21:28:32Z

Landed in ca2eec4, thank you, Shelley! 😃

Electron uses BoringSSL which does not support OCB . It is also possible to build OpenSSL without support for OCB for Node.js. This commit disables OCB if OPENSSL_NO_OCB is defined. PR-URL: #23635 Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>

nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. crypto Issues and PRs related to the crypto subsystem. labels Oct 13, 2018

tniessen approved these changes Oct 13, 2018

View reviewed changes

addaleax reviewed Oct 13, 2018

View reviewed changes

addaleax approved these changes Oct 13, 2018

View reviewed changes

addaleax reviewed Oct 13, 2018

View reviewed changes

mscdex reviewed Oct 14, 2018

View reviewed changes

src: remove OCB support when OPENSSL_NO_OCB is defined

5d4eeb4

sam-github reviewed Oct 15, 2018

View reviewed changes

tniessen approved these changes Oct 15, 2018

View reviewed changes

tniessen closed this Oct 16, 2018

codebytere mentioned this pull request Nov 27, 2018

v10.13.1 proposal #24675

Closed

codebytere mentioned this pull request Nov 29, 2018

v10.14.2 proposal #24727

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

src: remove OCB support when OPENSSL_NO_OCB is defined #23635

src: remove OCB support when OPENSSL_NO_OCB is defined #23635

codebytere commented Oct 13, 2018 •

edited

Loading

nodejs-github-bot commented Oct 13, 2018

davidben commented Oct 13, 2018

tniessen Oct 13, 2018

addaleax Oct 13, 2018

tniessen Oct 13, 2018

sam-github Oct 13, 2018

addaleax Oct 13, 2018

addaleax commented Oct 13, 2018

addaleax Oct 13, 2018

sam-github commented Oct 13, 2018

tniessen commented Oct 13, 2018 •

edited

Loading

mscdex Oct 14, 2018 •

edited

Loading

tniessen Oct 14, 2018

mscdex commented Oct 14, 2018

tniessen commented Oct 14, 2018

davidben commented Oct 14, 2018

sam-github Oct 15, 2018

tniessen Oct 15, 2018

sam-github Oct 15, 2018

sam-github commented Oct 15, 2018

tniessen left a comment

tniessen commented Oct 15, 2018 •

edited

Loading

davidben commented Oct 16, 2018

tniessen commented Oct 16, 2018

src: remove OCB support when OPENSSL_NO_OCB is defined #23635

src: remove OCB support when OPENSSL_NO_OCB is defined #23635

Conversation

codebytere commented Oct 13, 2018 • edited Loading

Checklist

nodejs-github-bot commented Oct 13, 2018

davidben commented Oct 13, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

addaleax commented Oct 13, 2018

Choose a reason for hiding this comment

sam-github commented Oct 13, 2018

tniessen commented Oct 13, 2018 • edited Loading

mscdex Oct 14, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mscdex commented Oct 14, 2018

tniessen commented Oct 14, 2018

davidben commented Oct 14, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sam-github commented Oct 15, 2018

tniessen left a comment

Choose a reason for hiding this comment

tniessen commented Oct 15, 2018 • edited Loading

davidben commented Oct 16, 2018

tniessen commented Oct 16, 2018

codebytere commented Oct 13, 2018 •

edited

Loading

tniessen commented Oct 13, 2018 •

edited

Loading

mscdex Oct 14, 2018 •

edited

Loading

tniessen commented Oct 15, 2018 •

edited

Loading