[
https://issues.apache.org/jira/browse/TS-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14255991#comment-14255991
]
Sudheer Vinukonda edited comment on TS-3153 at 4/13/15 12:51 AM:
-----------------------------------------------------------------
The main issue here is that when the SNI call back happens, the plugins have no
knowledge of the list of protocols that are accepted on the proxy port on which
the connection was accepted. This knowledge is available in the
{{SSLNextProtocolAccept}} object, but, the {{SSLNetVConnection}} object does
not currently have visibility/access to the {{SSLNextProtocolAccept}} object.
It simply has the {{SSLNextProtocolSet}} pointer directly.
Discussed with [~amc] and he suggested the following solution.
1. Add a pointer to {{SessionAccept}} (the generic base class for
{{SSLNextProtocolAccept}}) object <session_accept> in {{SSLNetVConnection}} (in
addition to the existing {{SSLNextProtocolSet}} pointer <npnSet>)
2. In {{SSLNextProtocolAccept::mainEvent}}, set the {{SessionAccept}} object
pointer in {{SSLNetVConnection}} to the {{SSLNextProtocolSessionAccept}} object
on {{NET_EVENT_ACCEPT}}.
With the above framework, a user plugin should be able to do the below:
1. Create a bunch of {{SSLNextProtocolSet}} (npnSet) objects (various possible
permutations/combinations of the available protocols (retrieved from acceptor
objects)) for each configured SNI for all the acceptor objects (based on the
available list of acceptor objects, {{SLL<SSLNextProtocolAccept>}}
ssl_plugin_acceptors). This step also makes sure the created npnSet objects are
validated against each the registered protocol list for each acceptor.
2. When a SNI call back happens, the plugin uses the SNI and the
netvc->session_accept to locate a custom npnSet. If a npnSet is available, it
updates the netvc->npnSet, otherwise just does nothing.
was (Author: sudheerv):
The issue here is that when the SNI call back happens, the plugins have no
knowledge of the list of protocols that are accepted on the proxy port on which
the connection was accepted. This knowledge is available in the
{{SSLNextProtocolAccept}} object, but, the {{SSLNetVConnection}} object does
not currently have visibility/access to the {{SSLNextProtocolAccept}} object.
It simply has the {{SSLNextProtocolSet}} pointer directly.
Discussed with [~amc] and he suggested the following solution.
1. Add a pointer to {{SessionAccept}} (the generic base class for
{{SSLNextProtocolAccept}}) object <session_accept> in {{SSLNetVConnection}} (in
addition to the existing {{SSLNextProtocolSet}} pointer <npnSet>)
2. In {{SSLNextProtocolAccept::mainEvent}}, set the {{SessionAccept}} object
pointer in {{SSLNetVConnection}} to the {{SSLNextProtocolSessionAccept}} object
on {{NET_EVENT_ACCEPT}}.
With the above framework, a user plugin should be able to do the below:
1. Create a bunch of {{SSLNextProtocolSet}} (npnSet) objects (various possible
permutations/combinations of the available protocols (retrieved from acceptor
objects)) for each configured SNI for all the acceptor objects (based on the
available list of acceptor objects, {{SLL<SSLNextProtocolAccept>}}
ssl_plugin_acceptors). This step also makes sure the created npnSet objects are
validated against each the registered protocol list for each acceptor.
2. When a SNI call back happens, the plugin uses the SNI and the
netvc->session_accept to locate a custom npnSet. If a npnSet is available, it
updates the netvc->npnSet, otherwise just does nothing.
> Ability to disable/modify protocols based on SNI information
> ------------------------------------------------------------
>
> Key: TS-3153
> URL: https://issues.apache.org/jira/browse/TS-3153
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP/2, SPDY
> Reporter: Bryan Call
> Assignee: Sudheer Vinukonda
> Fix For: 6.0.0
>
> Attachments: TS-3153.diff
>
>
> We are running into problems where certain origin servers are having issues
> when SPDY is enabled. It would be great to have more control over when
> protocols are enabled.
> One way to do this would be to add a protocol options to the entry in the
> ssl_multicert config. We wound then add additional entries for domains that
> need to disable the protocols. All protocols should be enabled by default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
