[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-tabpanel&focusedCommentId=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
[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] [Created] (TS-1808) openssl dynlock support
James Peach created TS-1808: --- Summary: 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 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-1779) Crash using SNI and ssl_ca_name
[ https://issues.apache.org/jira/browse/TS-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (TS-1778) remove extensions.config support
[ https://issues.apache.org/jira/browse/TS-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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-1330) Logging related segfault in 3.2.0
[
https://issues.apache.org/jira/browse/TS-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13629028#comment-13629028
]
Leif Hedstrom commented on TS-1330:
---
Saw this on the mailing list, wonder if the exceedingly long log entries is
triggering this bug ?
{code}
At 2013-04-11 19:27:39,Esmq wrote:
hi, ym
following is the log found in traffic.out
[Apr 10 22:36:45.190] Server {0x44faab90} NOTE: Traffic Server is skipping
the current log entry because its size exceeds the maximum line (entry) size
for an ascii l
og buffer
[Apr 10 22:49:44.566] Server {0x44faab90} NOTE: Traffic Server is skipping
the current log entry because its size exceeds the maximum line (entry) size
for an ascii l
og buffer
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/trafficserver-3.2.0/bin/traffic_server - STACK TRACE:
[0x4001c400]
{code}
> Logging related segfault in 3.2.0
> -
>
> Key: TS-1330
> URL: https://issues.apache.org/jira/browse/TS-1330
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.2.0
> Environment: ATS 3.2.0 on RHEL 6.2 64-bit
>Reporter: David Carlin
>Assignee: Leif Hedstrom
> Fix For: 3.3.3
>
>
> I observed the following crash once on one of our ATS boxes - possibly
> related to TS-1240
> Jul 2 13:56:56 l2 traffic_server[25853]: {0x2b0a391e1700} ERROR:
> [SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
> error: Connection reset by peer
> Jul 2 13:59:56 l2 kernel: [ET_NET 1][25855]: segfault at c ip
> 0058e083 sp 2b0a2982b740 error 6
> Jul 2 13:59:56 l2 kernel: [ET_NET 3][25857]: segfault at 84 ip
> 0058e083 sp 2b0a29a31740 error 6 in traffic_server[40+34]
> Jul 2 13:59:56 l2 kernel: in traffic_server[40+34]
> Jul 2 14:02:59 l2 traffic_cop[25901]: (test) read timeout [18 ]
> Jul 2 14:02:59 l2 traffic_cop[25901]: server heartbeat failed [1]
> Jul 2 14:03:08 l2 traffic_manager[25826]: {0x7f3f088607e0} FATAL:
> [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
> Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} FATAL: (last
> system error 104: Connection reset by peer)
> Jul 2 14:03:09 l2 traffic_cop[25901]: cannot find traffic_server [1]
> Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} ERROR:
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} ERROR: (last
> system error 32: Broken pipe)
> Jul 2 14:03:12 l2 traffic_cop[25901]: cop received child status signal
> [25826 35584]
> Jul 2 14:03:12 l2 traffic_cop[25901]: traffic_manager not running, making
> sure traffic_server is dead
> Jul 2 14:03:12 l2 traffic_cop[25901]: spawning traffic_manager
> Jul 2 14:03:13 l2 traffic_manager[18267]: NOTE: --- Manager Starting ---
> Jul 2 14:03:13 l2 traffic_manager[18267]: NOTE: Manager Version: Apache
> Traffic Server - traffic_manager - 3.2.0 - (build # 52518 on Jun 25 2012 at
> 18:22:12)
> Jul 2 14:03:13 l2 traffic_manager[18267]: {0x7fe63de3f7e0} STATUS: opened
> /home/y/logs/trafficserver/manager.log
> Jul 2 14:03:15 l2 traffic_server[18322]: NOTE: --- Server Starting ---
> Jul 2 14:03:15 l2 traffic_server[18322]: NOTE: Server Version: Apache
> Traffic Server - traffic_server - 3.2.0 - (build # 52518 on Jun 25 2012 at
> 18:22:31)
> Jul 2 14:03:15 l2 traffic_server[18322]: {0x2b77573ab860} STATUS: opened
> /home/y/logs/trafficserver/diags.log
> Jul 2 14:03:15 l2 traffic_server[18322]: {0x2b77573ab860} ERROR: Cannot
> insert duplicate!
> Jul 2 14:03:22 l2 traffic_cop[25901]: server heartbeat succeeded
> [Jul 2 13:56:56.304] Server {0x2b0a391e1700} ERROR:
> [SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
> error: Connection reset by peer
> NOTE: Traffic Server received Sig 11: Segmentation fault
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE:
> /home/y/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x3b54e0f4a0]
> /lib64/libpthread.so.0[0x3b54e0f4a0]
> /home/y/bin/traffic_server(_ZN9LogBuffer14checkout_writeEPmm+0x153)[0x58e083]
> /home/y/bin/traffic_server(_ZN9LogObject15_checkout_writeEPmm+0xa8)[0x5a64c8]
> /home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x2f0)[0x5a7e30]
> /home/y/bin/traffic_server(_ZN9LogBuffer14checkout_writeEPmm+0x153)[0x58e083]
> /home/y/bin/traffic_server(_ZN9LogObject15_checkout_writeEPmm+0xa8)[0x5a64c8]
> /home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x2f0)[0x5a7e30]
> /home/y/bin/traffic_ser
