[
https://issues.apache.org/jira/browse/PROTON-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13530290#comment-13530290
]
Philip Harvey commented on PROTON-181:
--------------------------------------
>From a proton-j point of view, I broadly agree with Ken's last comment.
Going back to Rafi's question, I actually think there are some scenarios where
SSL resume would no longer be possible. These scenarios are all of the form:
1. User does some work with domainA and session1.
2. session1 is interrupted
3. User wishes to resume session1 but with some settings that differ from those
in domainA. Currently, the possible settings are:
- credentials (surely this would usually preclude SSL-resume anyway)
- trusted CA db (ditto)
- toggle support for allowing connections to anonymous peers
- toggle support for byte-sniffing to automatically switch between plain or
SSL connections
I believe these scenarios are so rare that it's not worth supporting them, as
doing so increases the complexity of the API, and of the implementation.
There is of course nothing to stop us adding per-session overrides in the
future.
> SSL layer - deprecate old per-connection credentials API, introduce new
> top-level configuration domain
> ------------------------------------------------------------------------------------------------------
>
> Key: PROTON-181
> URL: https://issues.apache.org/jira/browse/PROTON-181
> Project: Qpid Proton
> Issue Type: Wish
> Components: proton-c, proton-j
> Affects Versions: 0.2
> Reporter: Ken Giusti
> Assignee: Ken Giusti
> Fix For: 0.3
>
>
> In the first two releases of the SSL layer, the model only provided a
> per-connection object (pn_ssl_t). Thus, all configuration had to be applied
> each time an SSL connection was created.
> As new capabilities were added to SSL, this model has proven to be
> inadequate.
> With session resume, a new top-level object was introduced: pn_ssl_domain_t.
> This object becomes a "factory" for pn_ssl_t connections. Common
> configuration, such as credentials and CA database, are configured at the
> pn_ssl_domain_t level, and are adopted by each connection (pn_ssl_t) that is
> created.
> This model not only reduces the configuration actions need by the app, but
> results in a cleaner SSL implementation since the underlying SSL libraries
> (OpenSSL and Java's SSL) use a very similar model.
> More detail of the new api can be seen in PROTON-136.
> The problem now become support of the old api. Behavior becomes a bit vague
> if we allow credential, etc, configuration on both the domain and the ssl
> connection. Given the brief exposure of the existing api, we'd like to drop
> support for the following existing SSL API methods:
> pn_ssl() - constructor
> pn_ssl_init()
> pn_ssl_set_credentials()
> pn_ssl_set_trusted_ca_db()
> The corresponding functionality would instead be available via the
> domain-based api.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
