Skip to content
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

Closed
Scottmitch opened this issue Oct 21, 2014 · 15 comments
Closed

NPN / ALPN extensions callbacks don't allow handshake failure #188

Scottmitch opened this issue Oct 21, 2014 · 15 comments

Comments

@Scottmitch
Copy link

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)?

@Scottmitch Scottmitch changed the title NPN / ALPN extensions no common protocols found NPN / ALPN extensions callbacks allow handshake failure Oct 21, 2014
@Scottmitch
Copy link
Author

@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 no_application_protocol(120) alert and in the case of NPN we used the handshake_failure(40) alert to fail the handshake (if callbacks indicated a failure was desired).

@Scottmitch Scottmitch changed the title NPN / ALPN extensions callbacks allow handshake failure NPN / ALPN extensions callbacks don't allow handshake failure Oct 22, 2014
@Scottmitch
Copy link
Author

Any updates or thoughts on this?

@Scottmitch
Copy link
Author

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?

@richsalz
Copy link
Contributor

yeah, it probably should be. can you bring it up on openssl-dev?

@Scottmitch
Copy link
Author

@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.

@richsalz
Copy link
Contributor

ah, yeah, you have to be a member of the list to post. i think nabble has a UI that lets you post

@Scottmitch
Copy link
Author

@richsalz - Join request sent.

@Scottmitch
Copy link
Author

Question posted to mailing list http://marc.info/?l=openssl-dev&m=143285528815940&w=2

@richsalz
Copy link
Contributor

See also http://rt.openssl.org/Ticket/Display.html?id=3463 (user/pass guest/guest)

@Scottmitch
Copy link
Author

@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?

@richsalz
Copy link
Contributor

Finally closing this in 1.1; we'll send the alert. code to land in repo shortly.

@Scottmitch
Copy link
Author

@richsalz - Thanks for the update! So this will not land in a 1.0.2 release?

@richsalz
Copy link
Contributor

nope. sorry.

asfgit pushed a commit to apache/tomcat that referenced this issue Apr 28, 2016
…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
christianpaquin referenced this issue in christianpaquin/openssl Dec 21, 2017
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
@normanmaurer
Copy link

@richsalz did this ever land in openssl ? I am trying to find the changeset but no luck so far :/

@richsalz
Copy link
Contributor

It was done in 1.1.0 and later. not backported as faras i know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants