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

Correctly handle non handshake commands when using SniHandler #4703

Closed
wants to merge 1 commit into from

Conversation

normanmaurer
Copy link
Member

Motivation:

As we can only handle handshake commands to parse SNI we should try to skip alert and change cipher spec commands a few times before we fallback to use a default SslContext.

Modifications:

  • Use default SslContext if no application data command was received
  • Use default SslContext if after 4 commands we not received a handshake command
  • Simplify code
  • Eliminate multiple volatile fields
  • Rename SslConstants to SslUtils
  • Share code between SslHandler and SniHandler by moving stuff to SslUtils

Result:

Correct handling of non handshake commands and cleaner code.

@normanmaurer
Copy link
Member Author

@trustin @nmittler @Scottmitch PTAL

@normanmaurer normanmaurer self-assigned this Jan 13, 2016
@normanmaurer normanmaurer added this to the 4.0.34.Final milestone Jan 13, 2016
@nmittler
Copy link
Member

@ejona86 might be interested as well

offset += extensionLength;
}
break loop;
} else {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if you structure this the opposite way, you can get rid of the break loop above:

if (in.readableBytes() < packetLength) {
    // client hello incomplete try again to decode once more data is ready.
    return;
}

...
// Fall-through

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you are right... let me fix this

Motivation:

As we can only handle handshake commands to parse SNI we should try to skip alert and change cipher spec commands a few times before we fallback to use a default SslContext.

Modifications:

- Use default SslContext if no application data command was received
- Use default SslContext if after 4 commands we not received a handshake command
- Simplify code
- Eliminate multiple volatile fields
- Rename SslConstants to SslUtils
- Share code between SslHandler and SniHandler by moving stuff to SslUtils

Result:

Correct handling of non handshake commands and cleaner code.
@trustin
Copy link
Member

trustin commented Jan 14, 2016

I wonder creating an extra object to reduce the number of volatile writes seems like an overkill to me.

Besides that, looks good to me. :-)

@normanmaurer
Copy link
Member Author

@trustin honestly the object is only created once and it seems more clean (as both fields just be updated together) so I would like to keep it like it is :)

@normanmaurer
Copy link
Member Author

Cherry-picked into 4.0 (27118ec) and 4.1 (3c5abaa)

@normanmaurer normanmaurer deleted the sni_decode branch January 14, 2016 19:56
@Scottmitch
Copy link
Member

lgtm!

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

Successfully merging this pull request may close these issues.

None yet

5 participants