[
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 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):
Discussed with [~amc] and he suggested the following solution:
1. Add a pointer to SessionAccept 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 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)
