Comments (5)
This kind of issue, combined with observing the original API did not work when upgrading TLS 1.2 to TLS 1.3, was why we removed the custom extensions API in BoringSSL. (BoringSSL does not use custom extensions to implement its QUIC API. We just taught the library how to handle the various QUIC extensions.)
While it's handy to allow callers to add extensions without the TLS library supporting them, it conflicts with wanting to be able to evolve the TLS library backwards-compatibly. We prefer APIs with semantics that can survive the TLS library moving to new versions or adopting new features.
from openssl.
I'm not sure I completely follow here:
-
To the question of who wins when custom extensions are registered twice, ossl_tls_add_custom_ext_intern checks for internal support prior to allowing the registration of an extension, so in that case OpenSSL wins, and, as you note, we are left with the unforseen potential change in behavior from end users. However, it would seem to me that custom extensions are only added when ratified by a standards document so (in an ideal world) the behavior should match, or at least be in compliance with whatever standard its added against. I understand that may not always occur
-
As for why quic implements a custom extension (I assume you're referring to the SSL_EXT_TLS1_3_ENCRYPTED_EXTENSION), I would guess that we weren't in a position to support that extension in TCP TLS or DTLS, but I'm unsure.
Ostensibly, if you were backporting borinssl implementations of QUIC to openssl 3.3, that should be done with openssls quic support disabled (but I'm just guessing there)
@hlandau @mattcaswell can you please comment here?
from openssl.
With 1 there's a problem where the extension communicates additional data that the application provides or vice versa. Whatever mechanism was used in the custom handler is not available to openssl, so the behavior will not match. I think we need to consider having custom handlers take priority if we want to really have compatibility.
With 2: why not use the boringssl api and build the openssl quic on top if this layering is an issue? Applications have two different nonconflicting paths to set up an SSL object: for the Boring API they call a specific function, for the OpenSSL one they inject a specific SSL method. I wouldn't be surprised if there are some rough edges, but it's conceptually doable.
Forcing a choice here means that administrators and vendors of shared libraries have to pick one or the other, with consequences for shipping applications today that use QUIC that we need to support, and for further applications that have to decide what QUIC stack to support. I suspect that particularly for servers the existing, deployed today server side stacks would win out over future unproven work.
from openssl.
As for why quic implements a custom extension (I assume you're referring to the SSL_EXT_TLS1_3_ENCRYPTED_EXTENSION), I would guess that we weren't in a position to support that extension in TCP TLS or DTLS, but I'm unsure
I assume @wbl is referring to this code:
Lines 758 to 768 in 067fbc0
At the time of writing that code I was seeking to keep the changes required to support QUIC in the core TLS code to an absolute minimum. I had refactored the record layer to enable the setting of a custom record layer. That enabled the QUIC code to set its own record layer without introducing knowledge of QUIC into the core TLS code. By the same thinking, this extension was something only useful for QUIC so I was seeking to keep it within the QUIC code, and so chose to use a custom extension to do that. It is certainly a valid alternative design to implement the extension in the normal way - but that would require the core TLS extensions code to be modified in some way to know only to use the extension in QUIC (probably with some extra "context" flag, e.g. SSL_EXT_QUIC_ONLY
)
from openssl.
@wbl To be clear — the custom extension (QUIC Transport Parameters) is only added by the QUIC code. So if you aren't using the OpenSSL QUIC stack, it shouldn't be causing any problems if you are trying to add QUIC Transport Parameters as a custom extension itself (even if OpenSSL is compiled with QUIC support enabled).
I'm not sure if that answers your question — let me know.
from openssl.
Related Issues (20)
- Minerva attack on power PC architecture HOT 16
- Minerva attack on ARM architecture HOT 7
- RFC 5280 X509 compliance issues in OpenSSL v3.1.1 or later HOT 9
- openssl ciphers -v doesn't list AES-CTR and AES-ECB cipher suits
- CI regression from the new hashtable support HOT 7
- Minerva attack on OpenSSL built without enable-ec_nistp_64_gcc_128 HOT 2
- Since OpenSSL 3.0
- openssl --version does not return on version 3.0.13 and 3.3.0 sparc v8 HOT 7
- OpenSSL Read/Write into a BIO_s_mem works only on first call per connection HOT 1
- Openssl speed reports error for RSA KEM keys using external providers in openssl3.2
- pkg-config files are no longer relocatable with 3.3 HOT 1
- `ERR_reason_error_string()` returns `NULL` for `no_application_protocol` alert HOT 4
- SM2 failed to generate public key from private key HOT 5
- Unable to verify LDAP CRL
- CMS Decryption fails randomly with BouncyCastle encrypted HOT 8
- pkcs12 - Bag attributes not written if ``-nokeys`` is used HOT 2
- `SSL_SESSION_set_time` incorrect documentation HOT 1
- Add EVP object caching to libctx
- AES CBC 128 decryption returns a wrong result
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openssl.