[jira] [Created] (TS-1807) shutdown on a write VIO to TSHttpConnect() doesn't propogate
William Bardwell created TS-1807: Summary: shutdown on a write VIO to TSHttpConnect() doesn't propogate Key: TS-1807 URL: https://issues.apache.org/jira/browse/TS-1807 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell In a plugin I am doing a TSHttpConnect() and then sending HTTP requests and getting responses. But when I try to do TSVIONBytesSet() and TSVConnShutdown() on the write vio (due to the client side being done sending requests) the write vio just sits there and never wakes up the other side, and the response side doesn't try to close up until an inactivity timeout happens. I think that PluginVC::do_io_shutdown() needs to do other_side-read_state.vio.reenable(); when a shutdown for write shows up. Then the otherside wakes up and sees the EOF due to the shutdown. -- 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
[jira] [Commented] (TS-1778) remove extensions.config support
[ https://issues.apache.org/jira/browse/TS-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13629334#comment-13629334 ] ASF subversion and git services commented on TS-1778: - Commit 80d1f32e8e110238048e7ee1e15bf959c7491e8f in branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=80d1f32 ] TS-1778: Remove vestigal extensions.config support remove extensions.config support - Key: TS-1778 URL: https://issues.apache.org/jira/browse/TS-1778 Project: Traffic Server Issue Type: Improvement Components: Core, Plugins Reporter: James Peach Assignee: James Peach Fix For: 3.3.2 plugin_init() has an old code path that initializes extensions.config if plugins are not enabled. Pretty sure that this is not supported any more; we should just remove the old extensions.config support. -- 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
[jira] [Commented] (TS-1779) Crash using SNI and ssl_ca_name
[ https://issues.apache.org/jira/browse/TS-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13629564#comment-13629564 ] James Peach commented on TS-1779: - I spent a bit of time trying to repro this with master, but failed. Can you send me some self-signed certificates, or steps/scripts to generate them? Crash using SNI and ssl_ca_name --- Key: TS-1779 URL: https://issues.apache.org/jira/browse/TS-1779 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: Rodney Assignee: James Peach Fix For: 3.3.2 When I add 'ssl_ca_name' to include a chain cert CA the traffic server fails to start with a core dump. It seems to be okay if I just have one entry in 'ssl_multicert.config' file but as soon as I use SNI the traffic server will not start with a core dump. This witnessed on 3.2.0 and currently 3.2.4 with Debian Squeeze. Example entries: ssl_cert_name=my1.crt ssl_key_name=my1.key ssl_ca_name=my1CA.crt ssl_cert_name=my2.crt ssl_key_name=my2.key ssl_ca_name=my2CA.crt #Default dest_ip=* ssl_cert_name=my1.crt ssl_key_name=my1.key ssl_ca_name=my1CA.crt -- 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
[jira] [Updated] (TS-1808) openssl dynlock support
[ https://issues.apache.org/jira/browse/TS-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1808: Fix Version/s: 3.3.3 Assignee: James Peach I guess I get this one ... openssl dynlock support --- Key: TS-1808 URL: https://issues.apache.org/jira/browse/TS-1808 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Assignee: James Peach Fix For: 3.3.3 OpenSSL has a thing called dynlock, which it uses to allocate locks on the fly, see CRYPTO_set_dynlock_create_callback() and friends. Apparently this can improve performance. We should implement OpenSSL dynlocks and measure. -- 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
[jira] [Commented] (TS-1467) Do something about client initiated renegotiation (SSL) DDoS
[ https://issues.apache.org/jira/browse/TS-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13629593#comment-13629593 ] James Peach commented on TS-1467: - Also check whether we should set: SSL_CTX_set_options(ctx, SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION) Do something about client initiated renegotiation (SSL) DDoS Key: TS-1467 URL: https://issues.apache.org/jira/browse/TS-1467 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: Leif Hedstrom Assignee: Phil Sorber Fix For: 3.3.3 https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks -- 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
