-
-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NPN / ALPN extensions callbacks don't allow handshake failure #188
Comments
@richsalz - FYI this is to continue our discussion about the ALPN / NPN failure behavior. The OpenJDK based implementations (jetty-alpn and jetty-npn) have been updated to support controlling the behavior at the granularity of each handshake (so not just a compile time flag or system property). I think this is equivalent to adding an additional return value to the openssl callbacks? In the case of ALPN we used the |
Any updates or thoughts on this? |
Now that HTTP/2 has been published as an RFC (and ALPN is already an RFC)....is there any chance of this getting re-prioritized? |
yeah, it probably should be. can you bring it up on openssl-dev? |
@richsalz - Done. Haven't received feedback that the post went through yet though. Not sure if I'm required to join before posting or if the post has to be reviewed before it makes it to the archives. |
ah, yeah, you have to be a member of the list to post. i think nabble has a UI that lets you post |
@richsalz - Join request sent. |
Question posted to mailing list http://marc.info/?l=openssl-dev&m=143285528815940&w=2 |
See also http://rt.openssl.org/Ticket/Display.html?id=3463 (user/pass guest/guest) |
@richsalz - I checked out the patch and it looks good. The only thing from your point of view is whether you want to make the fatal alert failure behavior in s_server optional or not. This would be to preserve existing behavior, even though it goes against the spec. What is the timeline on evaluating / merging / targeting this for a release? |
Finally closing this in 1.1; we'll send the alert. code to land in repo shortly. |
@richsalz - Thanks for the update! So this will not land in a 1.0.2 release? |
nope. sorry. |
…not permit the TLS handshake to be failed if the ALPN negotiation fails. git-svn-id: https://svn.apache.org/repos/asf/tomcat/trunk@1741501 13f79535-47bb-0310-9956-ffa450edef68
ff3986a removed hard paths (open-quantum-safe#193) f62bb02 Enabled and documented building on ARM32 (Raspberry Pi). (open-quantum-safe#179) 9dab6f6 Flags for configured algorithms generated in config.h (open-quantum-safe#177) 2d5eb13 Covscan defect fix (open-quantum-safe#189) a5b239d Updated README (open-quantum-safe#191) d7a72e2 Add checks to verify length of input data for McBits (open-quantum-safe#186) cbee5ef Vsoftco issue160 (open-quantum-safe#188) 581fbbb Initialize out-parameters to NULL (open-quantum-safe#183) 0d8a354 Properly separate SIDH CLN16 from SIDH CLN16 compressed (open-quantum-safe#181) 8bc8cd9 Added VisualStudio DLL build configurations (open-quantum-safe#182) fc522d6 Embed SIDH IQC REFERENCE parameters (open-quantum-safe#180) 40ffb4e Updated Windows build (added sig, fixed warnings, 2017 update) (open-quantum-safe#169) a329060 Update README.md (open-quantum-safe#178) fcbd0f3 KEX memory benchmarks (open-quantum-safe#171) b9854b4 Arm compilation (open-quantum-safe#170) f3e24e1 Link to algorithm data sheets. 28cc05a Added datasheets for SIDH and Picnic. (open-quantum-safe#166) git-subtree-dir: vendor/liboqs git-subtree-split: ff3986ab9585e521462fb28d24ed024328f609b9
@richsalz did this ever land in openssl ? I am trying to find the changeset but no luck so far :/ |
It was done in 1.1.0 and later. not backported as faras i know. |
The interface for the ALPN/NPN protocol selection callbacks and protocol selection notification callbacks do not allow for the handshake to fail. It is requested that the return value support for these methods be expanded to allow the handshake to fail. This may be desirable (and explicitly called out in the ALPN specification) in the event there are no common protocols found during the selection process, or if the select protocol is not acceptable.
For example:
ALPN RFC Section 3.2 specifies a new fatal alert definition
no_application_protocol(120)
which can be used. This is currently not defined in openssl.The NPN specification is not as explicit about the alert to be used in this case but it could just result in a generic handshake_failure alert (if the callbacks return the new failure value)?
The text was updated successfully, but these errors were encountered: