[jira] [Commented] (TS-3527) Add plugin hooks for SSL Session state access
[ https://issues.apache.org/jira/browse/TS-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15101904#comment-15101904 ] ASF GitHub Bot commented on TS-3527: Github user shinrich commented on the pull request: https://github.com/apache/trafficserver/pull/402#issuecomment-171990184 Yes, I agree that having a matching TSSslContextDestroy is a good idea even if it is just a wrapper for the openssl call at this point. I also like the idea of adding hook points to aid in coordination of session ticket handling. I had proposed something similar for coordinating ssl session state between servers (TS-3527). I had initial code but met with resistance to the idea and got pulled into other things. But I'd be very interested in coming back to that and making session restarts work better in a multi-server environment. > Add plugin hooks for SSL Session state access > - > > Key: TS-3527 > URL: https://issues.apache.org/jira/browse/TS-3527 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 6.2.0 > > > Add plugin hook functionality to allow hook into the SSL session state > lifecycle. This enables session state communication between ATS deployments > and additional statistical analysis. > One API proposal is at > http://network-geographics.com/ats/docs/ssl-session-api.en.html > [~briang] suggested merging this with the existing TS_SSL_SNI_HOOK. Will > have to look in more detail with the openssl implementations to see if we can > hook into to a single point that has access to the functionality needed by > both. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4134) Traffic Manager aborts on attempted privilege escalation when non-root.
[
https://issues.apache.org/jira/browse/TS-4134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15101911#comment-15101911
]
Alan M. Carroll commented on TS-4134:
-
As part of the patch I removed several {{#ifdef USE_POSIX_CAPS}} wrappers
around elevation calls. I didn't see any purpose to them except as guards for
when the elevation didn't work for non-POSIX. It's possible the elevation to
full super user privileges was considered excessive but there were no comments
to that effect and asking on IRC yielded no response.
> Traffic Manager aborts on attempted privilege escalation when non-root.
> ---
>
> Key: TS-4134
> URL: https://issues.apache.org/jira/browse/TS-4134
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 6.2.0
>Reporter: Peter Chou
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> Traffic Manager aborts since it cannot elevate access in mgmt/Rollback.cc and
> mgmt/LocalManager.cc. The root of the issue might be that the semantics of
> the ElevateAccess constructor argument was changed from (boolean,level) to
> just a (level) by commit 6a5f6241 or TS-306. It seems the ElevateAccess
> access( ) calls in these two files were not changed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4136) incoming http connection stats should be correct regardless of the HTTP version
[ https://issues.apache.org/jira/browse/TS-4136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-4136: --- Fix Version/s: 6.2.0 > incoming http connection stats should be correct regardless of the HTTP > version > --- > > Key: TS-4136 > URL: https://issues.apache.org/jira/browse/TS-4136 > Project: Traffic Server > Issue Type: Bug > Components: HTTP, HTTP/2, SPDY >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 6.2.0 > > > proxy.process.http.current_client_connections and > proxy.process.http.total_client_connections are inaccurate once you > introduction SPDY and HTTP2. The connections counts will be incremented once > per stream, not once per connection. > You can use the spdy and http2 specific counts to fix up the number, but we > should go ahead and fix this directly. Once ts-3612 is present, the HTTP1.1 > session protocol is separated out of the HTTP state machine making the fix > relatively straight forward. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4136) incoming http connection stats should be correct regardless of the HTTP version
[ https://issues.apache.org/jira/browse/TS-4136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs reassigned TS-4136: -- Assignee: Susan Hinrichs > incoming http connection stats should be correct regardless of the HTTP > version > --- > > Key: TS-4136 > URL: https://issues.apache.org/jira/browse/TS-4136 > Project: Traffic Server > Issue Type: Bug > Components: HTTP, HTTP/2, SPDY >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 6.2.0 > > > proxy.process.http.current_client_connections and > proxy.process.http.total_client_connections are inaccurate once you > introduction SPDY and HTTP2. The connections counts will be incremented once > per stream, not once per connection. > You can use the spdy and http2 specific counts to fix up the number, but we > should go ahead and fix this directly. Once ts-3612 is present, the HTTP1.1 > session protocol is separated out of the HTTP state machine making the fix > relatively straight forward. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4136) incoming http connection stats should be correct regardless of the HTTP version
Susan Hinrichs created TS-4136: -- Summary: incoming http connection stats should be correct regardless of the HTTP version Key: TS-4136 URL: https://issues.apache.org/jira/browse/TS-4136 Project: Traffic Server Issue Type: Bug Components: HTTP, HTTP/2, SPDY Reporter: Susan Hinrichs proxy.process.http.current_client_connections and proxy.process.http.total_client_connections are inaccurate once you introduction SPDY and HTTP2. The connections counts will be incremented once per stream, not once per connection. You can use the spdy and http2 specific counts to fix up the number, but we should go ahead and fix this directly. Once ts-3612 is present, the HTTP1.1 session protocol is separated out of the HTTP state machine making the fix relatively straight forward. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4137) Improve stripe inspector diagnostic output
Alan M. Carroll created TS-4137: --- Summary: Improve stripe inspector diagnostic output Key: TS-4137 URL: https://issues.apache.org/jira/browse/TS-4137 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Alan M. Carroll Use of the stripe inspector in a production environment indicates the need for some cleanup and additional information to be provided by the stripe inspector. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4137) Improve stripe inspector diagnostic output
[ https://issues.apache.org/jira/browse/TS-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-4137: Fix Version/s: 6.2.0 > Improve stripe inspector diagnostic output > -- > > Key: TS-4137 > URL: https://issues.apache.org/jira/browse/TS-4137 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Alan M. Carroll > Fix For: 6.2.0 > > > Use of the stripe inspector in a production environment indicates the need > for some cleanup and additional information to be provided by the stripe > inspector. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4137) Improve stripe inspector diagnostic output
[ https://issues.apache.org/jira/browse/TS-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-4137: --- Assignee: Alan M. Carroll > Improve stripe inspector diagnostic output > -- > > Key: TS-4137 > URL: https://issues.apache.org/jira/browse/TS-4137 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Fix For: 6.2.0 > > > Use of the stripe inspector in a production environment indicates the need > for some cleanup and additional information to be provided by the stripe > inspector. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4134) Traffic Manager aborts on attempted privilege escalation when non-root.
[ https://issues.apache.org/jira/browse/TS-4134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15102336#comment-15102336 ] Peter Chou commented on TS-4134: Alan, the problem was evident only when running as a non-root user. I applied your patch and it seems to be working fine now. It also seemed to fix another issue where running 'trafficserver start' would only start traffic_cop and subsequently traffic_manager would have to be started manually and separately. Thanks for explaining about the scoping/destructor/auto-de-elevate behavior and for the quick response. > Traffic Manager aborts on attempted privilege escalation when non-root. > --- > > Key: TS-4134 > URL: https://issues.apache.org/jira/browse/TS-4134 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 6.2.0 >Reporter: Peter Chou >Assignee: Alan M. Carroll > Fix For: 6.1.0 > > > Traffic Manager aborts since it cannot elevate access in mgmt/Rollback.cc and > mgmt/LocalManager.cc. The root of the issue might be that the semantics of > the ElevateAccess constructor argument was changed from (boolean,level) to > just a (level) by commit 6a5f6241 or TS-306. It seems the ElevateAccess > access( ) calls in these two files were not changed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4104) wrong return value while create a new ticket on ssl_callback_session_ticket()
[
https://issues.apache.org/jira/browse/TS-4104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15102348#comment-15102348
]
ASF GitHub Bot commented on TS-4104:
Github user bryancall commented on the pull request:
https://github.com/apache/trafficserver/pull/400#issuecomment-172061089
With and without the return code change I get:
[Jan 15 11:27:31.471] Server {0x7f231793e840} DEBUG: (ssl) create ticket for a new session.
[Jan 15 11:27:31.471] Server {0x7f231793e840} DEBUG: (ssl) ssl_callback_info ssl: 0x165d0c0 where: 8193 ret: 1
[Jan 15 11:27:31.471] Server {0x7f231793e840} DEBUG: (ssl) ssl_callback_info ssl: 0x165d0c0 where: 8193 ret: 1
[Jan 15 11:27:31.471] Server {0x7f231793e840} DEBUG: (ssl) ssl_callback_info ssl: 0x165d0c0 where: 8193 ret: 1
[Jan 15 11:27:31.471] Server {0x7f231793e840} DEBUG: (ssl) ssl_callback_info ssl: 0x165d0c0 where: 8193 ret: 1
[Jan 15 11:27:31.471] Server {0x7f231793e840} DEBUG: (ssl) ssl_callback_info ssl: 0x165d0c0 where: 32 ret: 1
[Jan 15 11:27:31.471] Server {0x7f231793e840} DEBUG: (ssl) ssl_callback_info ssl: 0x165d0c0 where: 8194 ret: 1
[Jan 15 11:27:31.471] Server {0x7f231793e840} DEBUG:
(ssl) trace=FALSE
[Jan 15 11:27:31.471] Server {0x7f231793e840} DEBUG:
(ssl) SSL server
handshake completed successfully
I am running Fedora 23 with updated package and
openssl-1.0.2e-3.fc23.x86_64. What OS are you running?
> wrong return value while create a new ticket on ssl_callback_session_ticket()
> -
>
> Key: TS-4104
> URL: https://issues.apache.org/jira/browse/TS-4104
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: Oknet Xu
> Fix For: 6.2.0
>
>
> from openssl online document:
> https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_tlsext_ticket_key_cb.html
> The return value of the cb function is used by OpenSSL to determine what
> further processing will occur. The following return values have meaning:
> 2
> This indicates that the ctx and hctx have been set and the session can
> continue on those parameters. Additionally it indicates that the session
> ticket is in a renewal period and should be replaced. The OpenSSL library
> will call cb again with an enc argument of 1 to set the new ticket (see
> RFC5077 3.3 paragraph 2).
> 1
> This indicates that the ctx and hctx have been set and the session can
> continue on those parameters.
> 0
> This indicates that it was not possible to set/retrieve a session ticket and
> the SSL/TLS session will continue by by negotiating a set of cryptographic
> parameters or using the alternate SSL/TLS resumption mechanism, session ids.
> If called with enc equal to 0 the library will call the cb again to get a new
> set of parameters.
> less than 0
> This indicates an error.
> {code}
> 1948 if (enc == 1) {
> 1949 const ssl_ticket_key_t &most_recent_key = keyblock->keys[0];
> 1950 memcpy(keyname, most_recent_key.key_name,
> sizeof(most_recent_key.key_name));
> 1951 RAND_pseudo_bytes(iv, EVP_MAX_IV_LENGTH);
> 1952 EVP_EncryptInit_ex(cipher_ctx, EVP_aes_128_cbc(), NULL,
> most_recent_key.aes_key, iv);
> 1953 HMAC_Init_ex(hctx, most_recent_key.hmac_secret,
> sizeof(most_recent_key.hmac_secret), evp_md_func, NULL);
> 1954
> 1955 Debug("ssl", "create ticket for a new session.");
> 1956 SSL_INCREMENT_DYN_STAT(ssl_total_tickets_created_stat);
> 1957 return 0;
> 1958 } else if (enc == 0) {
> {code}
> the ssl_callback_session_ticket() should return 1 after create a new ticket
> but 0 here.
> and the traffic.out log for current ATS release:
> {code}
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) create ticket for
> a new session.
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) ssl_callback_info
> ssl: 0x2b0544006840 where: 8193 ret: 1
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) ssl_callback_info
> ssl: 0x2b0544006840 where: 8193 ret: 1
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) ssl_callback_info
> ssl: 0x2b0544006840 where: 8193 ret: 1
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) ssl_callback_info
> ssl: 0x2b0544006840 where: 8193 ret: 1
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) ssl_callback_info
> ssl: 0x2b0544006840 where: 32 ret: 1
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) ssl_callback_info
> ssl: 0x2b0544006840 where: 8194 ret: 1
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) trace=FALSE
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) SSL server
> handshake completed successfully
> {code}
> the traffic.out log if return 1 here:
> {code}
> [Dec 30 12:47:16.838] Server {0x2b6ec9340700} DEBUG: (ssl) create ticket for
[jira] [Commented] (TS-4129) Support TSContSchedule in ts_lua plugin
[ https://issues.apache.org/jira/browse/TS-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15102508#comment-15102508 ] ASF GitHub Bot commented on TS-4129: Github user shukitchan commented on the pull request: https://github.com/apache/trafficserver/pull/420#issuecomment-172102643 nice catch on both cases. let me update the PR over the weekend after some tests on the new code. > Support TSContSchedule in ts_lua plugin > --- > > Key: TS-4129 > URL: https://issues.apache.org/jira/browse/TS-4129 > Project: Traffic Server > Issue Type: New Feature > Components: Lua, Plugins >Reporter: Kit Chan >Assignee: Kit Chan > Fix For: 6.2.0 > > > We want to allow to write lua script for ts_lua plugin to use > TSContSchedule() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4134) Traffic Manager aborts on attempted privilege escalation when non-root.
[ https://issues.apache.org/jira/browse/TS-4134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15102988#comment-15102988 ] ASF GitHub Bot commented on TS-4134: Github user jpeach commented on the pull request: https://github.com/apache/trafficserver/pull/425#issuecomment-172158012 This looks OK to me, though I would have preferred a smaller diff. > Traffic Manager aborts on attempted privilege escalation when non-root. > --- > > Key: TS-4134 > URL: https://issues.apache.org/jira/browse/TS-4134 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 6.2.0 >Reporter: Peter Chou >Assignee: Alan M. Carroll > Fix For: 6.1.0 > > > Traffic Manager aborts since it cannot elevate access in mgmt/Rollback.cc and > mgmt/LocalManager.cc. The root of the issue might be that the semantics of > the ElevateAccess constructor argument was changed from (boolean,level) to > just a (level) by commit 6a5f6241 or TS-306. It seems the ElevateAccess > access( ) calls in these two files were not changed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
