[jira] [Commented] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1

2014-07-30 Thread Nikolai Gorchilov (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079037#comment-14079037
 ] 

Nikolai Gorchilov commented on TS-2954:
---

[~shinrich], unfortunately it doesn't work for me, at least against 5.0.1 
tarballs.

proxy.config.http.use_client_target_addr = 2

Poisoning requests for http://i.ytimg.com/vi_webp/6eKYsYUlGB8/mqdefault.webp 
via wget -qSO/dev/null --header="Host: i.ytimg.com" 
http://91.239.13.61/vi_webp/6eKYsYUlGB8/mqdefault.webp

Here's the relevant http_trans log how the fake response gets cached, 
regardless of the invalid (91.239.13.61) IP of i.ytimg.com:

{noformat}
(http_trans) START HttpTransact::ModifyRequest
(http_trans) [ink_cluster_time] local: 1406705552, highest_delta: 0, cluster: 
1406705552
(http_trans) END HttpTransact::ModifyRequest
(http_trans) Checking if transaction wants to upgrade
(http_trans) Next action SM_ACTION_API_READ_REQUEST_HDR; 
HttpTransact::StartRemapRequest
(http_trans) START HttpTransact::StartRemapRequest
(http_trans) Before Remapping:
(http_trans) END HttpTransact::StartRemapRequest
(http_trans) Next action SM_ACTION_API_PRE_REMAP; HttpTransact::PerformRemap
(http_trans) Inside PerformRemap
(http_trans) Next action SM_ACTION_REMAP_REQUEST; HttpTransact::EndRemapRequest
(http_trans) START HttpTransact::EndRemapRequest
(http_trans) EndRemapRequest host is i.ytimg.com
(http_trans) After Remapping:
(http_trans) END HttpTransact::EndRemapRequest
(http_trans) Next action SM_ACTION_API_POST_REMAP; HttpTransact::HandleRequest
(http_trans) START HttpTransact::HandleRequest
(http_trans) [init_stat_vars_from_req] set req cont length to 0
(http_trans) [is_request_valid]no request header errors
(http_trans) [DecideCacheLookup] Will do cache lookup.
(http_trans) Next action SM_ACTION_CACHE_LOOKUP; __null
(http_trans) [HttpTransact::HandleCacheOpenRead]
(http_trans) CacheOpenRead -- miss
(http_trans) Next action SM_ACTION_DNS_LOOKUP; OSDNSLookup
(http_trans) [HttpTransact::OSDNSLookup] This was attempt 1
(http_trans) [OSDNSLookup] DNS lookup for O.S. successful IP: 91.239.13.61
(http_trans) Next action SM_ACTION_API_OS_DNS; HandleCacheOpenReadMiss
(http_trans) [HandleCacheOpenReadMiss] --- MISS
(http_trans) [build_request] removing host name from url
(http_trans) [build_request] request like cacheable and conditional headers 
removed
(http_trans) [ink_cluster_time] local: 1406705552, highest_delta: 0, cluster: 
1406705552
(http_trans) [build_request] request_sent_time: 1406705552
(http_trans) Next action next; __null
(http_trans) [HttpTransact::HandleResponse]
(http_trans) [ink_cluster_time] local: 1406705552, highest_delta: 0, cluster: 
1406705552
(http_trans) [HandleResponse] response_received_time: 1406705552
(http_trans) [is_response_valid] No errors in response
(http_trans) [handle_response_from_server] (hrfs)
(http_trans) [hrfs] connection alive
(http_trans) [handle_forward_server_connection_open] (hfsco)
(http_trans) [hfsco] cache action: CACHE_DO_WRITE
(http_trans) [handle_cache_operation_on_forward_server_response] (hcoofsr)
(http_trans) [is_response_cacheable] client permits storing
(http_trans) [is_response_cacheable] YES by default 
(http_trans) [hcoofsr] response is cacheable
(http_trans) [hcoofsr] response code: 200
(http_trans) [hcoofsr] cache write
(http_trans) [handle_content_length_header] RESPONSE cont len in hdr is 5216
(http_trans) [Squid code generation] Hit/Miss: 49, Log: 51, Hier: 50
{noformat}


> cache poisoning due to proxy.config.http.use_client_target_addr = 1
> ---
>
> Key: TS-2954
> URL: https://issues.apache.org/jira/browse/TS-2954
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, DNS, Security, TProxy
>Reporter: Nikolai Gorchilov
>Assignee: Susan Hinrichs
>Priority: Critical
> Fix For: 5.1.0
>
> Attachments: ts-2954.patch
>
>
> Current implementation of proxy.config.http.use_client_target_addr opens a 
> very simple attack vector for cache poisoning in transparent forwarding mode.
> An attacker (or malware installed on innocent end-user computer) puts a fake 
> IP for popular website like www.google.com or www.facebook.com in hosts file 
> on PC behind the proxy. Once an infected PC requests the webpage in question, 
> a cacheable fake response poisons the cache.
> In order to prevent such scenarios (as well as [some 
> others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a 
> mechanism known as [Host Header Forgery 
> Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery].
> In short, while requesting an URL from origin server IP as hinted by the 
> client, proxy makes independent DNS query in parallel in order to determine 
> if client supplied IP belongs to requested domain name. In case o

[jira] [Commented] (TS-2860) AArch64 support

2014-07-30 Thread Marcin Juszkiewicz (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079036#comment-14079036
 ] 

Marcin Juszkiewicz commented on TS-2860:


I will take a look but I am not sure will I be able to port it.

Can not provide access to ARM64 hardware yet.

> AArch64 support
> ---
>
> Key: TS-2860
> URL: https://issues.apache.org/jira/browse/TS-2860
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Build, Portability
>Reporter: Marcin Juszkiewicz
>Assignee: Leif Hedstrom
> Fix For: 5.1.0
>
> Attachments: trafficserver-aarch64.patch
>
>
> Out of the box traffic server does not build on AArch64 (64-bit ARM) 
> architecture.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1

2014-07-30 Thread Nikolai Gorchilov (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079037#comment-14079037
 ] 

Nikolai Gorchilov edited comment on TS-2954 at 7/30/14 8:05 AM:


[~shinrich], unfortunately it doesn't work for me, at least against 5.0.1 
tarballs.

proxy.config.http.use_client_target_addr = 2

Poisoning requests for http://i.ytimg.com/vi_webp/6eKYsYUlGB8/mqdefault.webp 
via wget -qSO/dev/null --header="Host: i.ytimg.com" 
http://91.239.13.61/vi_webp/6eKYsYUlGB8/mqdefault.webp

Here's the relevant http_trans log how the fake response gets cached, 
regardless of the invalid (91.239.13.61) IP of i.ytimg.com:

{noformat}
(http_trans) START HttpTransact::ModifyRequest
(http_trans) [ink_cluster_time] local: 1406705552, highest_delta: 0, cluster: 
1406705552
(http_trans) END HttpTransact::ModifyRequest
(http_trans) Checking if transaction wants to upgrade
(http_trans) Next action SM_ACTION_API_READ_REQUEST_HDR; 
HttpTransact::StartRemapRequest
(http_trans) START HttpTransact::StartRemapRequest
(http_trans) Before Remapping:
(http_trans) END HttpTransact::StartRemapRequest
(http_trans) Next action SM_ACTION_API_PRE_REMAP; HttpTransact::PerformRemap
(http_trans) Inside PerformRemap
(http_trans) Next action SM_ACTION_REMAP_REQUEST; HttpTransact::EndRemapRequest
(http_trans) START HttpTransact::EndRemapRequest
(http_trans) EndRemapRequest host is i.ytimg.com
(http_trans) After Remapping:
(http_trans) END HttpTransact::EndRemapRequest
(http_trans) Next action SM_ACTION_API_POST_REMAP; HttpTransact::HandleRequest
(http_trans) START HttpTransact::HandleRequest
(http_trans) [init_stat_vars_from_req] set req cont length to 0
(http_trans) [is_request_valid]no request header errors
(http_trans) [DecideCacheLookup] Will do cache lookup.
(http_trans) Next action SM_ACTION_CACHE_LOOKUP; __null
(http_trans) [HttpTransact::HandleCacheOpenRead]
(http_trans) CacheOpenRead -- miss
(http_trans) Next action SM_ACTION_DNS_LOOKUP; OSDNSLookup
(http_trans) [HttpTransact::OSDNSLookup] This was attempt 1
(http_trans) [OSDNSLookup] DNS lookup for O.S. successful IP: 91.239.13.61
(http_trans) Next action SM_ACTION_API_OS_DNS; HandleCacheOpenReadMiss
(http_trans) [HandleCacheOpenReadMiss] --- MISS
(http_trans) [build_request] removing host name from url
(http_trans) [build_request] request like cacheable and conditional headers 
removed
(http_trans) [ink_cluster_time] local: 1406705552, highest_delta: 0, cluster: 
1406705552
(http_trans) [build_request] request_sent_time: 1406705552
(http_trans) Next action next; __null
(http_trans) [HttpTransact::HandleResponse]
(http_trans) [ink_cluster_time] local: 1406705552, highest_delta: 0, cluster: 
1406705552
(http_trans) [HandleResponse] response_received_time: 1406705552
(http_trans) [is_response_valid] No errors in response
(http_trans) [handle_response_from_server] (hrfs)
(http_trans) [hrfs] connection alive
(http_trans) [handle_forward_server_connection_open] (hfsco)
(http_trans) [hfsco] cache action: CACHE_DO_WRITE
(http_trans) [handle_cache_operation_on_forward_server_response] (hcoofsr)
(http_trans) [is_response_cacheable] client permits storing
(http_trans) [is_response_cacheable] YES by default 
(http_trans) [hcoofsr] response is cacheable
(http_trans) [hcoofsr] response code: 200
(http_trans) [hcoofsr] cache write
(http_trans) [handle_content_length_header] RESPONSE cont len in hdr is 5216
(http_trans) [Squid code generation] Hit/Miss: 49, Log: 51, Hier: 50
{noformat}

The following line bothers me most:
{noformat}
(http_trans) [OSDNSLookup] DNS lookup for O.S. successful IP: 91.239.13.61
{noformat}


was (Author: ngorchilov):
[~shinrich], unfortunately it doesn't work for me, at least against 5.0.1 
tarballs.

proxy.config.http.use_client_target_addr = 2

Poisoning requests for http://i.ytimg.com/vi_webp/6eKYsYUlGB8/mqdefault.webp 
via wget -qSO/dev/null --header="Host: i.ytimg.com" 
http://91.239.13.61/vi_webp/6eKYsYUlGB8/mqdefault.webp

Here's the relevant http_trans log how the fake response gets cached, 
regardless of the invalid (91.239.13.61) IP of i.ytimg.com:

{noformat}
(http_trans) START HttpTransact::ModifyRequest
(http_trans) [ink_cluster_time] local: 1406705552, highest_delta: 0, cluster: 
1406705552
(http_trans) END HttpTransact::ModifyRequest
(http_trans) Checking if transaction wants to upgrade
(http_trans) Next action SM_ACTION_API_READ_REQUEST_HDR; 
HttpTransact::StartRemapRequest
(http_trans) START HttpTransact::StartRemapRequest
(http_trans) Before Remapping:
(http_trans) END HttpTransact::StartRemapRequest
(http_trans) Next action SM_ACTION_API_PRE_REMAP; HttpTransact::PerformRemap
(http_trans) Inside PerformRemap
(http_trans) Next action SM_ACTION_REMAP_REQUEST; HttpTransact::EndRemapRequest
(http_trans) START HttpTransact::EndRemapRequest
(http_trans) EndRemapRequest host is i.ytimg.com
(http_trans) After Remapping:
(http_trans)

[jira] [Commented] (TS-2860) AArch64 support

2014-07-30 Thread Marcin Juszkiewicz (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079190#comment-14079190
 ] 

Marcin Juszkiewicz commented on TS-2860:


Good news: looks that CK has support for gcc atomics. I added some small 
required changes and doing checks now.

> AArch64 support
> ---
>
> Key: TS-2860
> URL: https://issues.apache.org/jira/browse/TS-2860
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Build, Portability
>Reporter: Marcin Juszkiewicz
>Assignee: Leif Hedstrom
> Fix For: 5.1.0
>
> Attachments: trafficserver-aarch64.patch
>
>
> Out of the box traffic server does not build on AArch64 (64-bit ARM) 
> architecture.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1

2014-07-30 Thread Susan Hinrichs (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079202#comment-14079202
 ] 

Susan Hinrichs commented on TS-2954:


Ah, I was only considering the case of DNS games against the name in the URL.  
Not the case of an IP in the URL.  Obvious in retrospect.  Will get that case 
dealt with today.

> cache poisoning due to proxy.config.http.use_client_target_addr = 1
> ---
>
> Key: TS-2954
> URL: https://issues.apache.org/jira/browse/TS-2954
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, DNS, Security, TProxy
>Reporter: Nikolai Gorchilov
>Assignee: Susan Hinrichs
>Priority: Critical
> Fix For: 5.1.0
>
> Attachments: ts-2954.patch
>
>
> Current implementation of proxy.config.http.use_client_target_addr opens a 
> very simple attack vector for cache poisoning in transparent forwarding mode.
> An attacker (or malware installed on innocent end-user computer) puts a fake 
> IP for popular website like www.google.com or www.facebook.com in hosts file 
> on PC behind the proxy. Once an infected PC requests the webpage in question, 
> a cacheable fake response poisons the cache.
> In order to prevent such scenarios (as well as [some 
> others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a 
> mechanism known as [Host Header Forgery 
> Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery].
> In short, while requesting an URL from origin server IP as hinted by the 
> client, proxy makes independent DNS query in parallel in order to determine 
> if client supplied IP belongs to requested domain name. In case of 
> discrepancy between DNS and client IP, the transaction shall be flagged as 
> non-cacheable to avoid possible cache poisoning, while still serving the 
> origin response to the client.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1

2014-07-30 Thread Nikolai Gorchilov (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079228#comment-14079228
 ] 

Nikolai Gorchilov commented on TS-2954:
---

As this is TPROXY setup, there's neither hostname, nor ip address in the 
requested URL.

{noformat}
$ tcpflow -ci en1 net 91.239.13.61 and port 80
tcpflow[79736]: listening on en1
192.168.001.113.52084-091.239.013.061.00080: GET 
/vi_webp/6eKYsYUlGB8/mqdefault.webp HTTP/1.1
User-Agent: Wget/1.13 (darwin11.4.0)
Accept: */*
Host: i.ytimg.com
Connection: Keep-Alive
{noformat}

As you can see, the destination IP has been used by the wget itself - dst is 
091.239.013.061.00080

> cache poisoning due to proxy.config.http.use_client_target_addr = 1
> ---
>
> Key: TS-2954
> URL: https://issues.apache.org/jira/browse/TS-2954
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, DNS, Security, TProxy
>Reporter: Nikolai Gorchilov
>Assignee: Susan Hinrichs
>Priority: Critical
> Fix For: 5.1.0
>
> Attachments: ts-2954.patch
>
>
> Current implementation of proxy.config.http.use_client_target_addr opens a 
> very simple attack vector for cache poisoning in transparent forwarding mode.
> An attacker (or malware installed on innocent end-user computer) puts a fake 
> IP for popular website like www.google.com or www.facebook.com in hosts file 
> on PC behind the proxy. Once an infected PC requests the webpage in question, 
> a cacheable fake response poisons the cache.
> In order to prevent such scenarios (as well as [some 
> others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a 
> mechanism known as [Host Header Forgery 
> Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery].
> In short, while requesting an URL from origin server IP as hinted by the 
> client, proxy makes independent DNS query in parallel in order to determine 
> if client supplied IP belongs to requested domain name. In case of 
> discrepancy between DNS and client IP, the transaction shall be flagged as 
> non-cacheable to avoid possible cache poisoning, while still serving the 
> origin response to the client.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (TS-2970) Different crashes when using tr-pass

2014-07-30 Thread Nikolai Gorchilov (JIRA) 
Nikolai Gorchilov created TS-2970:
-

 Summary: Different crashes when using tr-pass
 Key: TS-2970
 URL: https://issues.apache.org/jira/browse/TS-2970
 Project: Traffic Server
  Issue Type: Bug
  Components: Core, HTTP
Reporter: Nikolai Gorchilov


ATS 5.0.1 Running under Linux 3+ kernel in TPROXY mode.

Same configuration runs without a single crash for weeks, but in the moment I 
enable tr-pass (8081:ip-in=127.0.0.1:tr-ful:tr-pass) on server_ports I get many 
crashes in matter of seconds to minutes after starting the ATS:


* No plugins, no interim storage enabled

{noformat}
FATAL: HttpSM.cc:2714: failed assert `event == HTTP_TUNNEL_EVENT_DONE`
/z/bin/traffic_server - STACK TRACE: 
/z/lib/libtsutil.so.5(ink_fatal_die+0x0)[0x2b52382e8067]
/z/lib/libtsutil.so.5(ink_get_rand()+0x0)[0x2b52382e6b28]
/z/bin/traffic_server(HttpSM::tunnel_handler(int, void*)+0x148)[0x5cf9aa]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0x333)[0x5cebeb]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server(CheckConnect::handle_connect(int, Event*)+0x2f0)[0x74313c]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server[0x743c82]
/z/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*, 
EThread*)+0x389)[0x7449c3]
/z/bin/traffic_server(write_to_net(NetHandler*, UnixNetVConnection*, 
EThread*)+0x79)[0x744638]
/z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x6f3)[0x73dc21]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x11e)[0x7664ca]
/z/bin/traffic_server(EThread::execute()+0x45b)[0x766aa1]
/z/bin/traffic_server[0x76598f]
/lib64/libpthread.so.0(+0x7034)[0x2b52398f4034]
/lib64/libc.so.6(clone+0x6d)[0x2b523a63eb5d]
{noformat}

* With enabled interim storage: without traffic while indexing the storage

{noformat}
NOTE: Traffic Server received Sig 11: Segmentation fault
/z/bin/traffic_server - STACK TRACE: 
/lib64/libpthread.so.0(+0xf280)[0x2b24483d2280]
/z/bin/traffic_server(dir_clean_range_interimvol(long, long, 
InterimCacheVol*)+0x7f)[0x6f8b9a]
/z/bin/traffic_server(InterimCacheVol::handle_recover_from_data(int, 
void*)+0xaba)[0x6e9da2]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server(AIOCallbackInternal::io_complete(int, 
void*)+0x3f)[0x6f210f]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x11e)[0x7664ca]
/z/bin/traffic_server(EThread::execute()+0xc9)[0x76670f]
/z/bin/traffic_server[0x76598f]
/lib64/libpthread.so.0(+0x7034)[0x2b24483ca034]
/lib64/libc.so.6(clone+0x6d)[0x2b2449114b5d]
{noformat}

* with some plugins enabled

{noformat}
FATAL: HttpSM.cc:3840: failed assert `pending_action == NULL`
/z/bin/traffic_server - STACK TRACE: 
/z/lib/libtsutil.so.5(ink_fatal_die+0x0)[0x2b8f03a97067]
/z/lib/libtsutil.so.5(ink_get_rand()+0x0)[0x2b8f03a95b28]
/z/bin/traffic_server(HttpSM::do_hostdb_lookup()+0x81)[0x5d3a91]
/z/bin/traffic_server(HttpSM::set_next_state()+0xa02)[0x5df0cc]
/z/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
(*)(HttpTransact::State*))+0x1ba)[0x5de6c2]
/z/bin/traffic_server(HttpSM::handle_api_return()+0x138)[0x5cb200]
/z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x883)[0x5cafb9]
/z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x1a5)[0x5ca6bf]
/z/bin/traffic_server(TSHttpTxnReenable+0x13e)[0x511d6e]
/z/lib/plugins/x3me_dscp.so(http_txn_hook(tsapi_cont*, TSEvent, 
void*)+0x236)[0x2b8f10532508]
/z/bin/traffic_server(INKContInternal::handle_event(int, void*)+0xaa)[0x506404]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server(APIHook::invoke(int, void*)+0x6a)[0x506d22]
/z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x612)[0x5cad48]
/z/bin/traffic_server(HttpSM::do_api_callout_internal()+0x1b7)[0x5d7823]
/z/bin/traffic_server(HttpSM::do_api_callout()+0x26)[0x5e5144]
/z/bin/traffic_server(HttpSM::set_next_state()+0x6d)[0x5de737]
/z/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
(*)(HttpTransact::State*))+0x1ba)[0x5de6c2]
/z/bin/traffic_server(HttpSM::handle_api_return()+0x138)[0x5cb200]
/z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x883)[0x5cafb9]
/z/bin/traffic_server(HttpSM::do_api_callout_internal()+0x1b7)[0x5d7823]
/z/bin/traffic_server(HttpSM::do_api_callout()+0x26)[0x5e5144]
/z/bin/traffic_server(HttpSM::set_next_state()+0x6d)[0x5de737]
/z/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
(*)(HttpTransact::State*))+0x1ba)[0x5de6c2]
/z/bin/traffic_server(HttpSM::set_next_state()+0x1b3)[0x5de87d]
/z/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
(*)(HttpTransact::State*))+0x1ba)[0x5de6c2]

[jira] [Updated] (TS-2970) Different crashes when using tr-pass

2014-07-30 Thread Nikolai Gorchilov (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolai Gorchilov updated TS-2970:
--

Affects Version/s: 5.0.1
   5.0.0

> Different crashes when using tr-pass
> 
>
> Key: TS-2970
> URL: https://issues.apache.org/jira/browse/TS-2970
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP
>Affects Versions: 5.0.0, 5.0.1
>Reporter: Nikolai Gorchilov
>
> ATS 5.0.1 Running under Linux 3+ kernel in TPROXY mode.
> Same configuration runs without a single crash for weeks, but in the moment I 
> enable tr-pass (8081:ip-in=127.0.0.1:tr-ful:tr-pass) on server_ports I get 
> many crashes in matter of seconds to minutes after starting the ATS:
> * No plugins, no interim storage enabled
> {noformat}
> FATAL: HttpSM.cc:2714: failed assert `event == HTTP_TUNNEL_EVENT_DONE`
> /z/bin/traffic_server - STACK TRACE: 
> /z/lib/libtsutil.so.5(ink_fatal_die+0x0)[0x2b52382e8067]
> /z/lib/libtsutil.so.5(ink_get_rand()+0x0)[0x2b52382e6b28]
> /z/bin/traffic_server(HttpSM::tunnel_handler(int, void*)+0x148)[0x5cf9aa]
> /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0x333)[0x5cebeb]
> /z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
> /z/bin/traffic_server(CheckConnect::handle_connect(int, 
> Event*)+0x2f0)[0x74313c]
> /z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
> /z/bin/traffic_server[0x743c82]
> /z/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*, 
> EThread*)+0x389)[0x7449c3]
> /z/bin/traffic_server(write_to_net(NetHandler*, UnixNetVConnection*, 
> EThread*)+0x79)[0x744638]
> /z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x6f3)[0x73dc21]
> /z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
> /z/bin/traffic_server(EThread::process_event(Event*, int)+0x11e)[0x7664ca]
> /z/bin/traffic_server(EThread::execute()+0x45b)[0x766aa1]
> /z/bin/traffic_server[0x76598f]
> /lib64/libpthread.so.0(+0x7034)[0x2b52398f4034]
> /lib64/libc.so.6(clone+0x6d)[0x2b523a63eb5d]
> {noformat}
> * With enabled interim storage: without traffic while indexing the storage
> {noformat}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /z/bin/traffic_server - STACK TRACE: 
> /lib64/libpthread.so.0(+0xf280)[0x2b24483d2280]
> /z/bin/traffic_server(dir_clean_range_interimvol(long, long, 
> InterimCacheVol*)+0x7f)[0x6f8b9a]
> /z/bin/traffic_server(InterimCacheVol::handle_recover_from_data(int, 
> void*)+0xaba)[0x6e9da2]
> /z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
> /z/bin/traffic_server(AIOCallbackInternal::io_complete(int, 
> void*)+0x3f)[0x6f210f]
> /z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
> /z/bin/traffic_server(EThread::process_event(Event*, int)+0x11e)[0x7664ca]
> /z/bin/traffic_server(EThread::execute()+0xc9)[0x76670f]
> /z/bin/traffic_server[0x76598f]
> /lib64/libpthread.so.0(+0x7034)[0x2b24483ca034]
> /lib64/libc.so.6(clone+0x6d)[0x2b2449114b5d]
> {noformat}
> * with some plugins enabled
> {noformat}
> FATAL: HttpSM.cc:3840: failed assert `pending_action == NULL`
> /z/bin/traffic_server - STACK TRACE: 
> /z/lib/libtsutil.so.5(ink_fatal_die+0x0)[0x2b8f03a97067]
> /z/lib/libtsutil.so.5(ink_get_rand()+0x0)[0x2b8f03a95b28]
> /z/bin/traffic_server(HttpSM::do_hostdb_lookup()+0x81)[0x5d3a91]
> /z/bin/traffic_server(HttpSM::set_next_state()+0xa02)[0x5df0cc]
> /z/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
> (*)(HttpTransact::State*))+0x1ba)[0x5de6c2]
> /z/bin/traffic_server(HttpSM::handle_api_return()+0x138)[0x5cb200]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x883)[0x5cafb9]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x1a5)[0x5ca6bf]
> /z/bin/traffic_server(TSHttpTxnReenable+0x13e)[0x511d6e]
> /z/lib/plugins/x3me_dscp.so(http_txn_hook(tsapi_cont*, TSEvent, 
> void*)+0x236)[0x2b8f10532508]
> /z/bin/traffic_server(INKContInternal::handle_event(int, 
> void*)+0xaa)[0x506404]
> /z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
> /z/bin/traffic_server(APIHook::invoke(int, void*)+0x6a)[0x506d22]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x612)[0x5cad48]
> /z/bin/traffic_server(HttpSM::do_api_callout_internal()+0x1b7)[0x5d7823]
> /z/bin/traffic_server(HttpSM::do_api_callout()+0x26)[0x5e5144]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x6d)[0x5de737]
> /z/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
> (*)(HttpTransact::State*))+0x1ba)[0x5de6c2]
> /z/bin/traffic_server(HttpSM::handle_api_return()+0x138)[0x5cb200]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x883)[0x5cafb9]
> /z/bin/traffic_server(HttpSM::do_api_callout_internal()+0x1b7)[0x5d7823]
> /z/bin/traffic_server(

[jira] [Commented] (TS-2367) Add OCSP (Online Certificate Status Protocol) Stapling Support

2014-07-30 Thread Feifei Cai (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079268#comment-14079268
 ] 

Feifei Cai commented on TS-2367:


Thanks to [~jpe...@apache.org] and [~bcall]!
I made some updates as following:
# Use schedule_every() to check/update response.
# Use spawn_event_threads() to spawn a thread for OCSP thread.
# All functions that return 1 or 0 should be declared bool: Done.
# d2i_OCSP_RESPONSE is a heavy conversion, so I do copy first, then release the 
lock to cinf as soon. I removed stapling_get_cached_response in callback 
function, and leave the conversion/check to OCSP update thread.
# Change configuration options with stapling in the name to ocsp: Done.
# I change query_responder() to use openssl's API, OCSP_sendreq_nbio, to 
implement the unblocking query with timeout option.

> Add OCSP (Online Certificate Status Protocol) Stapling Support 
> ---
>
> Key: TS-2367
> URL: https://issues.apache.org/jira/browse/TS-2367
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: HTTP, SSL
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: review
> Fix For: 5.1.0
>
> Attachments: TS-2367.diff, TS-2367.diff
>
>
> RFC:
> http://tools.ietf.org/html/rfc6066
> Overview:
> https://wiki.mozilla.org/Security/Server_Side_TLS#OCSP_Stapling
> http://en.wikipedia.org/wiki/OCSP_stapling
> There is support for this added into openssl 0.9.8g.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TS-2367) Add OCSP (Online Certificate Status Protocol) Stapling Support

2014-07-30 Thread Feifei Cai (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Feifei Cai updated TS-2367:
---

Attachment: TS-2367.diff

> Add OCSP (Online Certificate Status Protocol) Stapling Support 
> ---
>
> Key: TS-2367
> URL: https://issues.apache.org/jira/browse/TS-2367
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: HTTP, SSL
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: review
> Fix For: 5.1.0
>
> Attachments: TS-2367.diff, TS-2367.diff
>
>
> RFC:
> http://tools.ietf.org/html/rfc6066
> Overview:
> https://wiki.mozilla.org/Security/Server_Side_TLS#OCSP_Stapling
> http://en.wikipedia.org/wiki/OCSP_stapling
> There is support for this added into openssl 0.9.8g.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TS-2367) Add OCSP (Online Certificate Status Protocol) Stapling Support

2014-07-30 Thread Feifei Cai (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Feifei Cai updated TS-2367:
---

Attachment: (was: TS-2367.diff)

> Add OCSP (Online Certificate Status Protocol) Stapling Support 
> ---
>
> Key: TS-2367
> URL: https://issues.apache.org/jira/browse/TS-2367
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: HTTP, SSL
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: review
> Fix For: 5.1.0
>
> Attachments: TS-2367.diff, TS-2367.diff
>
>
> RFC:
> http://tools.ietf.org/html/rfc6066
> Overview:
> https://wiki.mozilla.org/Security/Server_Side_TLS#OCSP_Stapling
> http://en.wikipedia.org/wiki/OCSP_stapling
> There is support for this added into openssl 0.9.8g.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TS-2970) Different crashes when using tr-pass

2014-07-30 Thread Nikolai Gorchilov (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolai Gorchilov updated TS-2970:
--

Description: 
ATS 5.0.1 Running under Linux 3+ kernel in TPROXY mode.

Same configuration runs without a single crash for weeks, but in the moment I 
enable tr-pass (8081:ip-in=127.0.0.1:tr-ful:tr-pass) on server_ports I get many 
crashes in matter of seconds to minutes after starting the ATS:

{noformat}
FATAL: HttpSM.cc:2714: failed assert `event == HTTP_TUNNEL_EVENT_DONE`
/z/bin/traffic_server - STACK TRACE: 
/z/lib/libtsutil.so.5(ink_fatal_die+0x0)[0x2b52382e8067]
/z/lib/libtsutil.so.5(ink_get_rand()+0x0)[0x2b52382e6b28]
/z/bin/traffic_server(HttpSM::tunnel_handler(int, void*)+0x148)[0x5cf9aa]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0x333)[0x5cebeb]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server(CheckConnect::handle_connect(int, Event*)+0x2f0)[0x74313c]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server[0x743c82]
/z/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*, 
EThread*)+0x389)[0x7449c3]
/z/bin/traffic_server(write_to_net(NetHandler*, UnixNetVConnection*, 
EThread*)+0x79)[0x744638]
/z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x6f3)[0x73dc21]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x11e)[0x7664ca]
/z/bin/traffic_server(EThread::execute()+0x45b)[0x766aa1]
/z/bin/traffic_server[0x76598f]
/lib64/libpthread.so.0(+0x7034)[0x2b52398f4034]
/lib64/libc.so.6(clone+0x6d)[0x2b523a63eb5d]
{noformat}

{noformat}
FATAL: HttpSM.cc:1687: failed assert `0`
/z/bin/traffic_server - STACK TRACE: 
/z/lib/libtsutil.so.5(+0x1e837)[0x2b6545caa837]
/z/lib/libtsutil.so.5(+0x1d51f)[0x2b6545ca951f]
/z/bin/traffic_server(HttpSM::state_http_server_open(int, void*)+0xfd)[0x5a13cd]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x59ac88]
/z/bin/traffic_server[0x65313a]
/z/bin/traffic_server(HostDBContinuation::probeEvent(int, 
Event*)+0x27a)[0x65967a]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x736071]
/z/bin/traffic_server(EThread::execute()+0x2fb)[0x73692b]
/z/bin/traffic_server[0x73530a]
/lib64/libpthread.so.0(+0x7034)[0x2b65472b0034]
/lib64/libc.so.6(clone+0x6d)[0x2b6547ffab5d]
{noformat}

{noformat}
FATAL: HttpTunnel.cc:554: failed assert `active == false`
/z/bin/traffic_server - STACK TRACE: 
/z/lib/libtsutil.so.5(+0x1e837)[0x2b679373e837]
/z/lib/libtsutil.so.5(+0x1d51f)[0x2b679373d51f]
/z/bin/traffic_server[0x5d660f]
/z/bin/traffic_server(HttpSM::kill_this()+0x674)[0x59a974]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0x148)[0x59acf8]
/z/bin/traffic_server(CheckConnect::handle_connect(int, Event*)+0x119)[0x70d659]
/z/bin/traffic_server(UnixNetVConnection::mainEvent(int, 
Event*)+0x3f0)[0x716640]
/z/bin/traffic_server(InactivityCop::check_inactivity(int, 
Event*)+0x275)[0x708045]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x736071]
/z/bin/traffic_server(EThread::execute()+0x2fb)[0x73692b]
/z/bin/traffic_server[0x73530a]
/lib64/libpthread.so.0(+0x7034)[0x2b6794d44034]
/lib64/libc.so.6(clone+0x6d)[0x2b6795a8eb5d]
{noformat}

My configure options other than layout-related are:

{noformat}
--with-group=proxy \
--with-xml=libxml2 \
--disable-static \
--disable-static-libts \
--disable-spdy \
--enable-interim-cache \
--enable-tproxy \
--enable-hwloc \
--enable-experimental-plugins \
--enable-example-plugins
{noformat}

P.S. Report updated due to some --enable-debug related crashes, that weren't 
connected to tr-pass at all

  was:
ATS 5.0.1 Running under Linux 3+ kernel in TPROXY mode.

Same configuration runs without a single crash for weeks, but in the moment I 
enable tr-pass (8081:ip-in=127.0.0.1:tr-ful:tr-pass) on server_ports I get many 
crashes in matter of seconds to minutes after starting the ATS:


* No plugins, no interim storage enabled

{noformat}
FATAL: HttpSM.cc:2714: failed assert `event == HTTP_TUNNEL_EVENT_DONE`
/z/bin/traffic_server - STACK TRACE: 
/z/lib/libtsutil.so.5(ink_fatal_die+0x0)[0x2b52382e8067]
/z/lib/libtsutil.so.5(ink_get_rand()+0x0)[0x2b52382e6b28]
/z/bin/traffic_server(HttpSM::tunnel_handler(int, void*)+0x148)[0x5cf9aa]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0x333)[0x5cebeb]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server(CheckConnect::handle_connect(int, Event*)+0x2f0)[0x74313c]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server[0x743c82]
/z/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*, 
EThread*)+0x389)[0x7449c3]
/z/bin/traffic_server(write_to_net(NetHandler*, UnixNetVConnection*, 
EThread*)+0x79)[0x744638]
/z/bin/traffic_server(NetHandler::mainNetEvent(int, Ev

[jira] [Commented] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1

2014-07-30 Thread Susan Hinrichs (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079318#comment-14079318
 ] 

Susan Hinrichs commented on TS-2954:


The problem is that I didn't define what the new attributes for 
proxy.config.http.use_client_target_addr.  The other problem is that my brain 
doesn't work so well until after the 5th cup of coffee so I just noticed your 
setting now.

proxy.config.http.use_client_target_addr = 0 - Means ignore the client used 
address and rely on the proxy's DNS resolution of the host field (behavior 
unchanged)
proxy.config.http.use_client_target_addr = 1 - Means use the client used 
address, but do not cache if the client used address does not match one of the 
proxy's DNS resolved addresses
proxy.config.http.use_client_target_addr = 2 - Means the same as 1 in previous 
builds.  Use the client used address.  Cache in any case.  Do not validate 
against the proxy's DNS resolved addresses.

Originally I had proposed putting the new behavior on 2, but after talking with 
Alan, we decided it would be safer to change the behavior of the already 
deployed setting.  Folks who really want to live dangerously can change the 
setting to 2.  By default deployments will gain the security improvement.  

So your tests with proxy.config.http.use_client_target_addr = 2 are working as 
designed.  Sorry for not clarifying earlier.  Could you give it a try with 
proxy.config.http.use_client_target_addr = 1.  I did your experiment and things 
worked as I would expect.

The log message "(http_trans) [OSDNSLookup] DNS lookup for O.S. successful IP: 
91.239.13.61" is a bit confusing.  It is printing the IP address that has be 
calculated for the OS regardless of whether a DNS lookup has been done or not.  


> cache poisoning due to proxy.config.http.use_client_target_addr = 1
> ---
>
> Key: TS-2954
> URL: https://issues.apache.org/jira/browse/TS-2954
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, DNS, Security, TProxy
>Reporter: Nikolai Gorchilov
>Assignee: Susan Hinrichs
>Priority: Critical
> Fix For: 5.1.0
>
> Attachments: ts-2954.patch
>
>
> Current implementation of proxy.config.http.use_client_target_addr opens a 
> very simple attack vector for cache poisoning in transparent forwarding mode.
> An attacker (or malware installed on innocent end-user computer) puts a fake 
> IP for popular website like www.google.com or www.facebook.com in hosts file 
> on PC behind the proxy. Once an infected PC requests the webpage in question, 
> a cacheable fake response poisons the cache.
> In order to prevent such scenarios (as well as [some 
> others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a 
> mechanism known as [Host Header Forgery 
> Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery].
> In short, while requesting an URL from origin server IP as hinted by the 
> client, proxy makes independent DNS query in parallel in order to determine 
> if client supplied IP belongs to requested domain name. In case of 
> discrepancy between DNS and client IP, the transaction shall be flagged as 
> non-cacheable to avoid possible cache poisoning, while still serving the 
> origin response to the client.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1

2014-07-30 Thread Susan Hinrichs (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079318#comment-14079318
 ] 

Susan Hinrichs edited comment on TS-2954 at 7/30/14 2:32 PM:
-

The problem is that I didn't define what the new attributes for 
proxy.config.http.use_client_target_addr.  The other problem is that my brain 
doesn't work so well until after the 5th cup of coffee so I just noticed your 
setting now.

proxy.config.http.use_client_target_addr = 0 - Means ignore the client used 
address and rely on the proxy's DNS resolution of the host field (behavior 
unchanged)
proxy.config.http.use_client_target_addr = 1 - Means use the client used 
address, but do not cache if the client used address does not match one of the 
proxy's DNS resolved addresses
proxy.config.http.use_client_target_addr = 2 - Means the same as 1 in previous 
builds.  Use the client used address.  Cache in any case.  Do not validate 
against the proxy's DNS resolved addresses.

Originally I had proposed putting the new behavior on 2, but after talking with 
Alan, we decided it would be safer to change the behavior of the already 
deployed setting.  Folks who really want to live dangerously can change the 
setting to 2.  By default deployments will gain the security improvement.  

So your tests with proxy.config.http.use_client_target_addr = 2 are working as 
designed.  Sorry for not clarifying earlier.  Could you give it a try with 
proxy.config.http.use_client_target_addr = 1.  I did your experiment and things 
worked as I would expect.

The log message "(http_trans) [OSDNSLookup] DNS lookup for O.S. successful IP: 
91.239.13.61" is a bit confusing.  It is printing the IP address that has be 
calculated for the OS regardless of whether a DNS lookup has been done or not.  

You should be seeing a log message like "(http_trans) [is_response_cacheable] 
Lookup not validated.  Possible DNS cache poison.  Don't cache"


was (Author: shinrich):
The problem is that I didn't define what the new attributes for 
proxy.config.http.use_client_target_addr.  The other problem is that my brain 
doesn't work so well until after the 5th cup of coffee so I just noticed your 
setting now.

proxy.config.http.use_client_target_addr = 0 - Means ignore the client used 
address and rely on the proxy's DNS resolution of the host field (behavior 
unchanged)
proxy.config.http.use_client_target_addr = 1 - Means use the client used 
address, but do not cache if the client used address does not match one of the 
proxy's DNS resolved addresses
proxy.config.http.use_client_target_addr = 2 - Means the same as 1 in previous 
builds.  Use the client used address.  Cache in any case.  Do not validate 
against the proxy's DNS resolved addresses.

Originally I had proposed putting the new behavior on 2, but after talking with 
Alan, we decided it would be safer to change the behavior of the already 
deployed setting.  Folks who really want to live dangerously can change the 
setting to 2.  By default deployments will gain the security improvement.  

So your tests with proxy.config.http.use_client_target_addr = 2 are working as 
designed.  Sorry for not clarifying earlier.  Could you give it a try with 
proxy.config.http.use_client_target_addr = 1.  I did your experiment and things 
worked as I would expect.

The log message "(http_trans) [OSDNSLookup] DNS lookup for O.S. successful IP: 
91.239.13.61" is a bit confusing.  It is printing the IP address that has be 
calculated for the OS regardless of whether a DNS lookup has been done or not.  


> cache poisoning due to proxy.config.http.use_client_target_addr = 1
> ---
>
> Key: TS-2954
> URL: https://issues.apache.org/jira/browse/TS-2954
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, DNS, Security, TProxy
>Reporter: Nikolai Gorchilov
>Assignee: Susan Hinrichs
>Priority: Critical
> Fix For: 5.1.0
>
> Attachments: ts-2954.patch
>
>
> Current implementation of proxy.config.http.use_client_target_addr opens a 
> very simple attack vector for cache poisoning in transparent forwarding mode.
> An attacker (or malware installed on innocent end-user computer) puts a fake 
> IP for popular website like www.google.com or www.facebook.com in hosts file 
> on PC behind the proxy. Once an infected PC requests the webpage in question, 
> a cacheable fake response poisons the cache.
> In order to prevent such scenarios (as well as [some 
> others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a 
> mechanism known as [Host Header Forgery 
> Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery].
> In short, while requesting an URL from origin server IP as hinted by the 
> client, proxy makes

[jira] [Commented] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1

2014-07-30 Thread Nikolai Gorchilov (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079366#comment-14079366
 ] 

Nikolai Gorchilov commented on TS-2954:
---

Oh, I see.

It makes sense to apply the new logic by default when using client target 
address and the current insecure logic to be explicitly activated by using the 
new value of 2.

After setting proxy.config.http.use_client_target_addr = 1 it seems to be 
working as expected. At least in lab tests:

{noformat}
(http_trans) START HttpTransact::ModifyRequest
(http_trans) [ink_cluster_time] local: 1406732859, highest_delta: 0, cluster: 
1406732859
(http_trans) END HttpTransact::ModifyRequest
(http_trans) Checking if transaction wants to upgrade
(http_trans) Next action SM_ACTION_API_READ_REQUEST_HDR; 
HttpTransact::StartRemapRequest
(http_trans) START HttpTransact::StartRemapRequest
(http_trans) Before Remapping:
(http_trans) END HttpTransact::StartRemapRequest
(http_trans) Next action SM_ACTION_API_PRE_REMAP; HttpTransact::PerformRemap
(http_trans) Inside PerformRemap
(http_trans) Next action SM_ACTION_REMAP_REQUEST; HttpTransact::EndRemapRequest
(http_trans) START HttpTransact::EndRemapRequest
(http_trans) EndRemapRequest host is i.ytimg.com
(http_trans) After Remapping:
(http_trans) END HttpTransact::EndRemapRequest
(http_trans) Next action SM_ACTION_API_POST_REMAP; HttpTransact::HandleRequest
(http_trans) START HttpTransact::HandleRequest
(http_trans) [init_stat_vars_from_req] set req cont length to 0
(http_trans) [is_request_valid]no request header errors
(http_trans) [DecideCacheLookup] Will do cache lookup.
(http_trans) Next action SM_ACTION_CACHE_LOOKUP; __null
(http_trans) [HttpTransact::HandleCacheOpenRead]
(http_trans) CacheOpenRead -- miss
(http_trans) Next action SM_ACTION_DNS_LOOKUP; OSDNSLookup
(http_trans) [ink_cluster_time] local: 1406732859, highest_delta: 0, cluster: 
1406732859
(http_trans) [HttpTransact::OSDNSLookup] This was attempt 1
(http_trans) [OSDNSLookup] DNS lookup for O.S. successful IP: 91.239.13.61
(http_trans) Next action SM_ACTION_API_OS_DNS; HandleCacheOpenReadMiss
(http_trans) [HandleCacheOpenReadMiss] --- MISS
(http_trans) [build_request] removing host name from url
(http_trans) [build_request] request like cacheable and conditional headers 
removed
(http_trans) [ink_cluster_time] local: 1406732859, highest_delta: 0, cluster: 
1406732859
(http_trans) [build_request] request_sent_time: 1406732859
(http_trans) Next action next; __null
(http_trans) [HttpTransact::HandleResponse]
(http_trans) [ink_cluster_time] local: 1406732859, highest_delta: 0, cluster: 
1406732859
(http_trans) [HandleResponse] response_received_time: 1406732859
(http_trans) [is_response_valid] No errors in response
(http_trans) [handle_response_from_server] (hrfs)
(http_trans) [hrfs] connection alive
(http_trans) [handle_forward_server_connection_open] (hfsco)
(http_trans) [hfsco] cache action: CACHE_DO_WRITE
(http_trans) [handle_cache_operation_on_forward_server_response] (hcoofsr)
(http_trans) [is_response_cacheable] Lookup not validated.  Possible DNS cache 
poison.  Don't cache
(http_trans) [hcoofsr] response is not cacheable
(http_trans) [hcoofsr] response code: 200
(http_trans) [handle_content_length_header] RESPONSE cont len in hdr is 5216
(http_trans) [Squid code generation] Hit/Miss: 49, Log: 51, Hier: 50
{noformat}

Planing for production trial tomorrow. Once done, will get back to you with 
results.

Thanks!

> cache poisoning due to proxy.config.http.use_client_target_addr = 1
> ---
>
> Key: TS-2954
> URL: https://issues.apache.org/jira/browse/TS-2954
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, DNS, Security, TProxy
>Reporter: Nikolai Gorchilov
>Assignee: Susan Hinrichs
>Priority: Critical
> Fix For: 5.1.0
>
> Attachments: ts-2954.patch
>
>
> Current implementation of proxy.config.http.use_client_target_addr opens a 
> very simple attack vector for cache poisoning in transparent forwarding mode.
> An attacker (or malware installed on innocent end-user computer) puts a fake 
> IP for popular website like www.google.com or www.facebook.com in hosts file 
> on PC behind the proxy. Once an infected PC requests the webpage in question, 
> a cacheable fake response poisons the cache.
> In order to prevent such scenarios (as well as [some 
> others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a 
> mechanism known as [Host Header Forgery 
> Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery].
> In short, while requesting an URL from origin server IP as hinted by the 
> client, proxy makes independent DNS query in parallel in order to determine 
> if client supplied IP belongs to requested domain name. In case of 
>

[jira] [Commented] (TS-2969) setTargetHeapUtilization:0.25 06-28 13:21:08.421 06-28 13:21:08.421

2014-07-30 Thread James Peach (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079377#comment-14079377
 ] 

James Peach commented on TS-2969:
-

I don't know what this means. [~interfacin69] could you give some more details?

>  setTargetHeapUtilization:0.25 06-28 13:21:08.421 06-28 13:21:08.421
> 
>
> Key: TS-2969
> URL: https://issues.apache.org/jira/browse/TS-2969
> Project: Traffic Server
>  Issue Type: Task
>  Components: Console, DNS, ICP, Management API, Manager, Security
>Reporter: Angelo Lomonaco
>Assignee: Leif Hedstrom
>
>  setTargetHeapUtilization:0.25 06-28 13:21:08.421 06-28 13:21:08.421



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1

2014-07-30 Thread Nikolai Gorchilov (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079429#comment-14079429
 ] 

Nikolai Gorchilov commented on TS-2954:
---

Unfortunately, the following assert emerged just seconds after deployment in 
production:

{noformat}
FATAL: HttpTransactHeaders.cc:675: failed assert `header->presence(mask) == 
mask`
/z/bin/traffic_server - STACK TRACE: 
/z/lib/libtsutil.so.5(+0x1e837)[0x2b515c66d837]
/z/lib/libtsutil.so.5(+0x1d51f)[0x2b515c66c51f]
/z/bin/traffic_server[0x5d17f2]
/z/bin/traffic_server(HttpTransact::build_request(HttpTransact::State*, 
HTTPHdr*, HTTPHdr*, HTTPVersion)+0xa0)[0x5b28d0]
/z/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x1f9)[0x5c89c9]
/z/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
(*)(HttpTransact::State*))+0x66)[0x58e3a6]
/z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c43]
/z/bin/traffic_server(HttpSM::set_next_state()+0x1e8)[0x5a0518]
/z/bin/traffic_server(HttpSM::do_hostdb_lookup()+0x27a)[0x58e89a]
/z/bin/traffic_server(HttpSM::set_next_state()+0xcf8)[0x5a1028]
/z/bin/traffic_server(HttpSM::state_read_server_response_header(int, 
void*)+0x1df)[0x59b66f]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x59add8]
/z/bin/traffic_server[0x715245]
/z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1ed)[0x707a1d]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x736361]
/z/bin/traffic_server(EThread::execute()+0x4fc)[0x736e1c]
/z/bin/traffic_server[0x7355fa]
/lib64/libpthread.so.0(+0x7034)[0x2b515dc73034]
/lib64/libc.so.6(clone+0x6d)[0x2b515e9bdb5d]
{noformat}


> cache poisoning due to proxy.config.http.use_client_target_addr = 1
> ---
>
> Key: TS-2954
> URL: https://issues.apache.org/jira/browse/TS-2954
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, DNS, Security, TProxy
>Reporter: Nikolai Gorchilov
>Assignee: Susan Hinrichs
>Priority: Critical
> Fix For: 5.1.0
>
> Attachments: ts-2954.patch
>
>
> Current implementation of proxy.config.http.use_client_target_addr opens a 
> very simple attack vector for cache poisoning in transparent forwarding mode.
> An attacker (or malware installed on innocent end-user computer) puts a fake 
> IP for popular website like www.google.com or www.facebook.com in hosts file 
> on PC behind the proxy. Once an infected PC requests the webpage in question, 
> a cacheable fake response poisons the cache.
> In order to prevent such scenarios (as well as [some 
> others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a 
> mechanism known as [Host Header Forgery 
> Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery].
> In short, while requesting an URL from origin server IP as hinted by the 
> client, proxy makes independent DNS query in parallel in order to determine 
> if client supplied IP belongs to requested domain name. In case of 
> discrepancy between DNS and client IP, the transaction shall be flagged as 
> non-cacheable to avoid possible cache poisoning, while still serving the 
> origin response to the client.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1

2014-07-30 Thread Nikolai Gorchilov (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079429#comment-14079429
 ] 

Nikolai Gorchilov edited comment on TS-2954 at 7/30/14 4:21 PM:


Unfortunately, the following assert emerged just seconds after deployment in 
production:

{noformat}
FATAL: HttpTransactHeaders.cc:675: failed assert `header->presence(mask) == 
mask`
/z/bin/traffic_server - STACK TRACE: 
/z/lib/libtsutil.so.5(+0x1e837)[0x2b515c66d837]
/z/lib/libtsutil.so.5(+0x1d51f)[0x2b515c66c51f]
/z/bin/traffic_server[0x5d17f2]
/z/bin/traffic_server(HttpTransact::build_request(HttpTransact::State*, 
HTTPHdr*, HTTPHdr*, HTTPVersion)+0xa0)[0x5b28d0]
/z/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x1f9)[0x5c89c9]
/z/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
(*)(HttpTransact::State*))+0x66)[0x58e3a6]
/z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c43]
/z/bin/traffic_server(HttpSM::set_next_state()+0x1e8)[0x5a0518]
/z/bin/traffic_server(HttpSM::do_hostdb_lookup()+0x27a)[0x58e89a]
/z/bin/traffic_server(HttpSM::set_next_state()+0xcf8)[0x5a1028]
/z/bin/traffic_server(HttpSM::state_read_server_response_header(int, 
void*)+0x1df)[0x59b66f]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x59add8]
/z/bin/traffic_server[0x715245]
/z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1ed)[0x707a1d]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x736361]
/z/bin/traffic_server(EThread::execute()+0x4fc)[0x736e1c]
/z/bin/traffic_server[0x7355fa]
/lib64/libpthread.so.0(+0x7034)[0x2b515dc73034]
/lib64/libc.so.6(clone+0x6d)[0x2b515e9bdb5d]
{noformat}

Could it be related to refresh check of already cached result?


was (Author: ngorchilov):
Unfortunately, the following assert emerged just seconds after deployment in 
production:

{noformat}
FATAL: HttpTransactHeaders.cc:675: failed assert `header->presence(mask) == 
mask`
/z/bin/traffic_server - STACK TRACE: 
/z/lib/libtsutil.so.5(+0x1e837)[0x2b515c66d837]
/z/lib/libtsutil.so.5(+0x1d51f)[0x2b515c66c51f]
/z/bin/traffic_server[0x5d17f2]
/z/bin/traffic_server(HttpTransact::build_request(HttpTransact::State*, 
HTTPHdr*, HTTPHdr*, HTTPVersion)+0xa0)[0x5b28d0]
/z/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x1f9)[0x5c89c9]
/z/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
(*)(HttpTransact::State*))+0x66)[0x58e3a6]
/z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c43]
/z/bin/traffic_server(HttpSM::set_next_state()+0x1e8)[0x5a0518]
/z/bin/traffic_server(HttpSM::do_hostdb_lookup()+0x27a)[0x58e89a]
/z/bin/traffic_server(HttpSM::set_next_state()+0xcf8)[0x5a1028]
/z/bin/traffic_server(HttpSM::state_read_server_response_header(int, 
void*)+0x1df)[0x59b66f]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x59add8]
/z/bin/traffic_server[0x715245]
/z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1ed)[0x707a1d]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x736361]
/z/bin/traffic_server(EThread::execute()+0x4fc)[0x736e1c]
/z/bin/traffic_server[0x7355fa]
/lib64/libpthread.so.0(+0x7034)[0x2b515dc73034]
/lib64/libc.so.6(clone+0x6d)[0x2b515e9bdb5d]
{noformat}


> cache poisoning due to proxy.config.http.use_client_target_addr = 1
> ---
>
> Key: TS-2954
> URL: https://issues.apache.org/jira/browse/TS-2954
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, DNS, Security, TProxy
>Reporter: Nikolai Gorchilov
>Assignee: Susan Hinrichs
>Priority: Critical
> Fix For: 5.1.0
>
> Attachments: ts-2954.patch
>
>
> Current implementation of proxy.config.http.use_client_target_addr opens a 
> very simple attack vector for cache poisoning in transparent forwarding mode.
> An attacker (or malware installed on innocent end-user computer) puts a fake 
> IP for popular website like www.google.com or www.facebook.com in hosts file 
> on PC behind the proxy. Once an infected PC requests the webpage in question, 
> a cacheable fake response poisons the cache.
> In order to prevent such scenarios (as well as [some 
> others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a 
> mechanism known as [Host Header Forgery 
> Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery].
> In short, while requesting an URL from origin server IP as hinted by the 
> client, proxy makes independent DNS query in parallel in order to determine 
> if client supplied IP belongs to requested domain name. In case of 
> discrepancy between DNS and client IP, the transaction shall be flagged as 
> non-cacheable to avoid possible cache poisoning, while still serving t

[jira] [Created] (TS-2971) Authproxy plugin has inconsistent debug symbol

2014-07-30 Thread Miles Libbey (JIRA) 
Miles Libbey created TS-2971:


 Summary: Authproxy plugin has inconsistent debug symbol
 Key: TS-2971
 URL: https://issues.apache.org/jira/browse/TS-2971
 Project: Traffic Server
  Issue Type: Improvement
  Components: Plugins
Reporter: Miles Libbey


The authproxy plugin has a debug tag of AuthProxy.  Most (all?) plugins use 
their name as the debug symbol. Consistency makes it easier to debug, 
especially in a complex interaction plugin like authproxy.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TS-2971) Authproxy plugin has inconsistent debug symbol

2014-07-30 Thread Miles Libbey (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Miles Libbey updated TS-2971:
-

Affects Version/s: 5.1.1

> Authproxy plugin has inconsistent debug symbol
> --
>
> Key: TS-2971
> URL: https://issues.apache.org/jira/browse/TS-2971
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Affects Versions: 5.1.1
>Reporter: Miles Libbey
>
> The authproxy plugin has a debug tag of AuthProxy.  Most (all?) plugins use 
> their name as the debug symbol. Consistency makes it easier to debug, 
> especially in a complex interaction plugin like authproxy.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2969) setTargetHeapUtilization:0.25 06-28 13:21:08.421 06-28 13:21:08.421

2014-07-30 Thread Leif Hedstrom (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079475#comment-14079475
 ] 

Leif Hedstrom commented on TS-2969:
---

Hmmm, yeah, and why is it it assigned to me? :)


>  setTargetHeapUtilization:0.25 06-28 13:21:08.421 06-28 13:21:08.421
> 
>
> Key: TS-2969
> URL: https://issues.apache.org/jira/browse/TS-2969
> Project: Traffic Server
>  Issue Type: Task
>  Components: Console, DNS, ICP, Management API, Manager, Security
>Reporter: Angelo Lomonaco
>Assignee: Leif Hedstrom
>
>  setTargetHeapUtilization:0.25 06-28 13:21:08.421 06-28 13:21:08.421



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2802) Add SNI support for origin servers

2014-07-30 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079478#comment-14079478
 ] 

ASF subversion and git services commented on TS-2802:
-

Commit c030977ab94cc05b48e7a578b9fa1de4949b026d in trafficserver's branch 
refs/heads/master from [~sunwei]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c030977 ]

TS-2802: add SNI support for origin server connections

Set the SNI name when making SSL origin server connections. Update
IP address literal parsing to accept ptr+len pairs as well as
NUL-terminated strings. This required removing default arguments
in the ConstBuffer constructor, since they cause nasty implicit
conversions.


> Add SNI support for origin servers
> --
>
> Key: TS-2802
> URL: https://issues.apache.org/jira/browse/TS-2802
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Bryan Call
>Assignee: James Peach
>  Labels: Review
> Fix For: 5.1.0
>
> Attachments: TS-2802.diff, TS-2802_without_changing_interface.diff
>
>
> test to an origin that requires SNI
> {code}
> [bcall@cat ~]$ tail -1 /usr/local/etc/trafficserver/remap.config
> map http://foo.yahoo.com 
> https://www.mnot.net/blog/2014/05/09/if_you_can_read_this_youre_sniing
> [bcall@cat ~]$ curl -H 'Host: foo.yahoo.com' http://localhost:8080/; echo
> TLS SNI Required.
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TS-2969) setTargetHeapUtilization:0.25 06-28 13:21:08.421 06-28 13:21:08.421

2014-07-30 Thread Leif Hedstrom (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2969:
--

Component/s: (was: Manager)
 (was: Security)
 (was: Console)

>  setTargetHeapUtilization:0.25 06-28 13:21:08.421 06-28 13:21:08.421
> 
>
> Key: TS-2969
> URL: https://issues.apache.org/jira/browse/TS-2969
> Project: Traffic Server
>  Issue Type: Task
>  Components: DNS, ICP, Management API
>Reporter: Angelo Lomonaco
>Assignee: Leif Hedstrom
>
>  setTargetHeapUtilization:0.25 06-28 13:21:08.421 06-28 13:21:08.421



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2957) sslheaders plugin

2014-07-30 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079504#comment-14079504
 ] 

ASF subversion and git services commented on TS-2957:
-

Commit f1350fa0ceb609fd70dc2c1a7807ef4e5e9aa3a4 in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f1350fa ]

TS-2957: add new sslheaders plugin

The sslheaders plugin injects information about the SSL session
into the client request, the server request or both. It can be used
to transmit client SSL information (eg, SSL certificate, certificate
subject, etc) to origin servers.


> sslheaders plugin
> -
>
> Key: TS-2957
> URL: https://issues.apache.org/jira/browse/TS-2957
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.1.0
>
>
> The sslheaders plugin injects information about the SSL session into the 
> client request, the server request or both. It can be used to transmit client 
> SSL informatin (eg, SSL certificate, certificate subject, etc) to origin 
> servers.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2971) Authproxy plugin has inconsistent debug symbol

2014-07-30 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079535#comment-14079535
 ] 

ASF subversion and git services commented on TS-2971:
-

Commit c37ca5d032033c339151e2cd59e12ce333ecea1f in trafficserver's branch 
refs/heads/master from [~mlibbey]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c37ca5d ]

TS-2971 Change capitilization of authproxy debug symbols to make it consistent


> Authproxy plugin has inconsistent debug symbol
> --
>
> Key: TS-2971
> URL: https://issues.apache.org/jira/browse/TS-2971
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Affects Versions: 5.1.1
>Reporter: Miles Libbey
>
> The authproxy plugin has a debug tag of AuthProxy.  Most (all?) plugins use 
> their name as the debug symbol. Consistency makes it easier to debug, 
> especially in a complex interaction plugin like authproxy.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (TS-2722) Authproxy: incorrect use of TSHttpConnect by passing destination ip as parameter

2014-07-30 Thread Leif Hedstrom (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom reassigned TS-2722:
-

Assignee: Leif Hedstrom  (was: James Peach)

> Authproxy: incorrect use of TSHttpConnect by passing destination ip as 
> parameter
> 
>
> Key: TS-2722
> URL: https://issues.apache.org/jira/browse/TS-2722
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Leif Hedstrom
> Fix For: 5.1.0
>
>
> We have previously discussed this in email thread with james. It seems the 
> authproxy plugin is calling TSHttpConnect and passes the destination ip as 
> parameter to this api instead of the connecting ip.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TS-2972) authproxy: Investigate if we can run this (configurable) in a different hook

2014-07-30 Thread Leif Hedstrom (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2972:
--

Fix Version/s: 5.1.0

> authproxy: Investigate if we can run this (configurable) in a different hook
> 
>
> Key: TS-2972
> URL: https://issues.apache.org/jira/browse/TS-2972
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
> Fix For: 5.1.0
>
>
> The issue is that without a (global) configuration to force us to go through 
> the DNS hook on cache hits, we can not use authproxy to protect on cache hits 
> (the plugin is bypassed).
> The setting is proxy.config.http.doc_in_cache_skip_dns, and it was added for 
> a very valid reason: If the entry in HostDB is stale, we can not serve out of 
> cache while it's doing the DNS lookup. This blocks all requests on that URL 
> until DNS has finished, which in some cases can take a long time (we had a 
> problem where some 3rd party DNS vendor could take up to 1s to resolve).
> My idea / hope is to make authproxy support running in a different hook, such 
> that it always can get called. However, the wrinkle is that this is also a 
> remap plugin, so whatever hook we pick, it has to happen after remap.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (TS-2972) authproxy: Investigate if we can run this (configurable) in a different hook

2014-07-30 Thread Leif Hedstrom (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom reassigned TS-2972:
-

Assignee: Leif Hedstrom

> authproxy: Investigate if we can run this (configurable) in a different hook
> 
>
> Key: TS-2972
> URL: https://issues.apache.org/jira/browse/TS-2972
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 5.1.0
>
>
> The issue is that without a (global) configuration to force us to go through 
> the DNS hook on cache hits, we can not use authproxy to protect on cache hits 
> (the plugin is bypassed).
> The setting is proxy.config.http.doc_in_cache_skip_dns, and it was added for 
> a very valid reason: If the entry in HostDB is stale, we can not serve out of 
> cache while it's doing the DNS lookup. This blocks all requests on that URL 
> until DNS has finished, which in some cases can take a long time (we had a 
> problem where some 3rd party DNS vendor could take up to 1s to resolve).
> My idea / hope is to make authproxy support running in a different hook, such 
> that it always can get called. However, the wrinkle is that this is also a 
> remap plugin, so whatever hook we pick, it has to happen after remap.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (TS-2972) authproxy: Investigate if we can run this (configurable) in a different hook

2014-07-30 Thread Leif Hedstrom (JIRA) 
Leif Hedstrom created TS-2972:
-

 Summary: authproxy: Investigate if we can run this (configurable) 
in a different hook
 Key: TS-2972
 URL: https://issues.apache.org/jira/browse/TS-2972
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Reporter: Leif Hedstrom


The issue is that without a (global) configuration to force us to go through 
the DNS hook on cache hits, we can not use authproxy to protect on cache hits 
(the plugin is bypassed).

The setting is proxy.config.http.doc_in_cache_skip_dns, and it was added for a 
very valid reason: If the entry in HostDB is stale, we can not serve out of 
cache while it's doing the DNS lookup. This blocks all requests on that URL 
until DNS has finished, which in some cases can take a long time (we had a 
problem where some 3rd party DNS vendor could take up to 1s to resolve).

My idea / hope is to make authproxy support running in a different hook, such 
that it always can get called. However, the wrinkle is that this is also a 
remap plugin, so whatever hook we pick, it has to happen after remap.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TS-2972) authproxy: Investigate if we can run this (configurable) in a different hook

2014-07-30 Thread Leif Hedstrom (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2972:
--

Issue Type: Improvement  (was: Bug)

> authproxy: Investigate if we can run this (configurable) in a different hook
> 
>
> Key: TS-2972
> URL: https://issues.apache.org/jira/browse/TS-2972
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
> Fix For: 5.1.0
>
>
> The issue is that without a (global) configuration to force us to go through 
> the DNS hook on cache hits, we can not use authproxy to protect on cache hits 
> (the plugin is bypassed).
> The setting is proxy.config.http.doc_in_cache_skip_dns, and it was added for 
> a very valid reason: If the entry in HostDB is stale, we can not serve out of 
> cache while it's doing the DNS lookup. This blocks all requests on that URL 
> until DNS has finished, which in some cases can take a long time (we had a 
> problem where some 3rd party DNS vendor could take up to 1s to resolve).
> My idea / hope is to make authproxy support running in a different hook, such 
> that it always can get called. However, the wrinkle is that this is also a 
> remap plugin, so whatever hook we pick, it has to happen after remap.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2967) failed assert if ssl_multicert.config doesn't exist

2014-07-30 Thread Jack Bates (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079566#comment-14079566
 ] 

Jack Bates commented on TS-2967:


I'm happy to axe those asserts
(you know this stuff far better than I do)
but I worry you might want them if you accidentally call 
{{ConfigProcessor::get()}} with an invalid index? (Say from another place where 
{{ConfigProcessor::get()}} is used.)

What about checking if {{configid}} is initialized in 
{{SSLCertificateConfig::acquire()}} and {{SSLCertificateConfig::release()}}?

{code}
--- a/iocore/net/SSLConfig.cc
+++ b/iocore/net/SSLConfig.cc
@@ -339,12 +339,16 @@ SSLCertificateConfig::reconfigure()
 SSLCertLookup *
 SSLCertificateConfig::acquire()
 {
-  return (SSLCertLookup *)configProcessor.get(configid);
+  if (configid != 0) {
+return (SSLCertLookup *)configProcessor.get(configid);
+  }
 }
 
 void
 SSLCertificateConfig::release(SSLCertLookup * lookup)
 {
-  configProcessor.release(configid, lookup);
+  if (configid != 0) {
+configProcessor.release(configid, lookup);
+  }
 }
 
{code}

> failed assert if ssl_multicert.config doesn't exist
> ---
>
> Key: TS-2967
> URL: https://issues.apache.org/jira/browse/TS-2967
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jack Bates
>
> If an ssl_multicert.config file doesn't exist then 
> SSLParseCertificateConfiguration() returns false (SSLUtils.cc line 1435)
> and SSLCertificateConfig::reconfigure() doesn't initialize configid 
> (SSLConfig.cc line 333)
> Then when SSLRecRawStatSyncCount() calls SSLCertificateConfig::acquire() 
> (SSLUtils.cc line 502)
> it calls ConfigProcessor::get() with configid zero (SSLConfig.cc line 342)
> and there's an ink_assert(id != 0) (ProxyConfig.cc line 175)
> One way to avoid the failed assert is if SSLCertificateConfig::acquire() and 
> SSLCertificateConfig::release() only call ConfigProcessor::get/release() if 
> (configid !=0)
> Another way might be if SSLCertificateConfig::reconfigure() initialized 
> configid with configProcessor.set(configid, NULL) if 
> SSLParseCertificateConfiguration() returns false?
> Or SSLParseCertificateConfiguration() could treat a nonexistent 
> ssl_multicert.config the same as it treats a blank file? ({{touch 
> ssl_multicert.config}} makes the failed assert go away.)
> Or maybe there's another better way to avoid the failed assert?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TS-2722) Authproxy: incorrect use of TSHttpConnect by passing destination ip as parameter

2014-07-30 Thread Leif Hedstrom (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2722:
--

Fix Version/s: (was: sometime)
   5.1.0

> Authproxy: incorrect use of TSHttpConnect by passing destination ip as 
> parameter
> 
>
> Key: TS-2722
> URL: https://issues.apache.org/jira/browse/TS-2722
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Kit Chan
>Assignee: Leif Hedstrom
> Fix For: 5.1.0
>
>
> We have previously discussed this in email thread with james. It seems the 
> authproxy plugin is calling TSHttpConnect and passes the destination ip as 
> parameter to this api instead of the connecting ip.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (TS-2973) add milestones support to the xdebug plugin

2014-07-30 Thread James Peach (JIRA) 
James Peach created TS-2973:
---

 Summary: add milestones support to the xdebug plugin
 Key: TS-2973
 URL: https://issues.apache.org/jira/browse/TS-2973
 Project: Traffic Server
  Issue Type: Improvement
  Components: Plugins
Reporter: James Peach


The slow logging feature published the HTTP transaction milestones, but it's 
also useful to be able to generate a request and see the milestones for just 
that request. Adding this feature to the xdebug plugin since it's a general 
debugging capability.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2973) add milestones support to the xdebug plugin

2014-07-30 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079584#comment-14079584
 ] 

ASF subversion and git services commented on TS-2973:
-

Commit ff45432a88dbfc1b1354676a60f056f4830799e6 in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ff45432 ]

TS-2973: add x-milestones header to the xdebug plugin

The X-Milestones header contains detailed information about how
long the transaction took to traverse portions of the HTTP state
machine. The timing information is obtained from the TSHttpTxnMilestoneGet
API. Each milestone value is a fractional number of seconds since
the beginning of the transaction.


> add milestones support to the xdebug plugin
> ---
>
> Key: TS-2973
> URL: https://issues.apache.org/jira/browse/TS-2973
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: James Peach
> Fix For: 5.1.0
>
>
> The slow logging feature published the HTTP transaction milestones, but it's 
> also useful to be able to generate a request and see the milestones for just 
> that request. Adding this feature to the xdebug plugin since it's a general 
> debugging capability.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (TS-2973) add milestones support to the xdebug plugin

2014-07-30 Thread James Peach (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach resolved TS-2973.
-

   Resolution: Fixed
Fix Version/s: 5.1.0
 Assignee: James Peach

> add milestones support to the xdebug plugin
> ---
>
> Key: TS-2973
> URL: https://issues.apache.org/jira/browse/TS-2973
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.1.0
>
>
> The slow logging feature published the HTTP transaction milestones, but it's 
> also useful to be able to generate a request and see the milestones for just 
> that request. Adding this feature to the xdebug plugin since it's a general 
> debugging capability.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (TS-2974) add epic metrics plugin

2014-07-30 Thread James Peach (JIRA) 
James Peach created TS-2974:
---

 Summary: add epic metrics plugin
 Key: TS-2974
 URL: https://issues.apache.org/jira/browse/TS-2974
 Project: Traffic Server
  Issue Type: Improvement
  Components: Metrics, Plugins
Reporter: James Peach


Add a new plugin to support the Epic monitoring system, 
.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2974) add epic metrics plugin

2014-07-30 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079630#comment-14079630
 ] 

ASF subversion and git services commented on TS-2974:
-

Commit bde10b7785bddd43a56ab1ef0a5f33463ed3e712 in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=bde10b7 ]

TS-2974: new epic metrics plugin

Add a new plugin to publich metrics into the Epic monitoring system,
https://code.google.com/p/epicnms/.


> add epic metrics plugin
> ---
>
> Key: TS-2974
> URL: https://issues.apache.org/jira/browse/TS-2974
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Metrics, Plugins
>Reporter: James Peach
>
> Add a new plugin to support the Epic monitoring system, 
> .



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2957) sslheaders plugin

2014-07-30 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079664#comment-14079664
 ] 

ASF subversion and git services commented on TS-2957:
-

Commit de1bcc7a666f7e690b07e47ac5e7c468b2dc853e in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=de1bcc7 ]

TS-2957: fix linux build warnings


> sslheaders plugin
> -
>
> Key: TS-2957
> URL: https://issues.apache.org/jira/browse/TS-2957
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.1.0
>
>
> The sslheaders plugin injects information about the SSL session into the 
> client request, the server request or both. It can be used to transmit client 
> SSL informatin (eg, SSL certificate, certificate subject, etc) to origin 
> servers.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (TS-2974) add epic metrics plugin

2014-07-30 Thread James Peach (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach resolved TS-2974.
-

   Resolution: Fixed
Fix Version/s: 5.1.0
 Assignee: James Peach

> add epic metrics plugin
> ---
>
> Key: TS-2974
> URL: https://issues.apache.org/jira/browse/TS-2974
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Metrics, Plugins
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.1.0
>
>
> Add a new plugin to support the Epic monitoring system, 
> .



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (TS-2975) add x-cache header to the xdebug plugin

2014-07-30 Thread James Peach (JIRA) 
James Peach created TS-2975:
---

 Summary: add x-cache header to the xdebug plugin
 Key: TS-2975
 URL: https://issues.apache.org/jira/browse/TS-2975
 Project: Traffic Server
  Issue Type: Improvement
  Components: Plugins
Reporter: James Peach


Add xdebug plugin support for publishing the cache lookup status in a 
{{X-Cache}} header.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2975) add x-cache header to the xdebug plugin

2014-07-30 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079693#comment-14079693
 ] 

ASF subversion and git services commented on TS-2975:
-

Commit 0c8f9343c2d55c2469af36e368e0b7a86cf6def5 in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0c8f934 ]

TS-2975: add x-cache header to publish cache lookup status


> add x-cache header to the xdebug plugin
> ---
>
> Key: TS-2975
> URL: https://issues.apache.org/jira/browse/TS-2975
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: James Peach
> Fix For: 5.1.0
>
>
> Add xdebug plugin support for publishing the cache lookup status in a 
> {{X-Cache}} header.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (TS-2975) add x-cache header to the xdebug plugin

2014-07-30 Thread James Peach (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach resolved TS-2975.
-

   Resolution: Fixed
Fix Version/s: 5.1.0
 Assignee: James Peach

> add x-cache header to the xdebug plugin
> ---
>
> Key: TS-2975
> URL: https://issues.apache.org/jira/browse/TS-2975
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.1.0
>
>
> Add xdebug plugin support for publishing the cache lookup status in a 
> {{X-Cache}} header.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (TS-2976) lib records build cleanup

2014-07-30 Thread James Peach (JIRA) 
James Peach created TS-2976:
---

 Summary: lib records build cleanup
 Key: TS-2976
 URL: https://issues.apache.org/jira/browse/TS-2976
 Project: Traffic Server
  Issue Type: Improvement
  Components: Cleanup, Core
Reporter: James Peach


The lib records build is really hard to understand, which compatibility 
defines, building the same code with different options. Let's do some cleanup.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2976) lib records build cleanup

2014-07-30 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079755#comment-14079755
 ] 

ASF subversion and git services commented on TS-2976:
-

Commit a2584bf29cf0945a33c3bdd1c35c0322aba96315 in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a2584bf ]

TS-2976: lib records build cleanup

Use the correct constant for MGMT_SIGNAL_SAC_SERVER_DOWN.

Remove REC_SignalManager compatibility define.

Replace REC_SignalWarning and REC_SignalError macros with
RecSignalWarning.

Remove the LOCAL_MANAGER and PROCESS_MANAGER defines.  With this
change, we no longer compile any code differently depending on the
LOCAL_MANAGER and PROCESS_MANAGER defines.  Where we build libraries
that have local and process variants, we just stub a small set of
symbols to do the right thing.


> lib records build cleanup
> -
>
> Key: TS-2976
> URL: https://issues.apache.org/jira/browse/TS-2976
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cleanup, Core
>Reporter: James Peach
>
> The lib records build is really hard to understand, which compatibility 
> defines, building the same code with different options. Let's do some cleanup.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (TS-2976) lib records build cleanup

2014-07-30 Thread James Peach (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach resolved TS-2976.
-

   Resolution: Fixed
Fix Version/s: 5.1.0
 Assignee: James Peach

> lib records build cleanup
> -
>
> Key: TS-2976
> URL: https://issues.apache.org/jira/browse/TS-2976
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cleanup, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.1.0
>
>
> The lib records build is really hard to understand, which compatibility 
> defines, building the same code with different options. Let's do some cleanup.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (TS-2971) Authproxy plugin has inconsistent debug symbol

2014-07-30 Thread James Peach (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach resolved TS-2971.
-

   Resolution: Fixed
Fix Version/s: 5.1.0
 Assignee: Miles Libbey

> Authproxy plugin has inconsistent debug symbol
> --
>
> Key: TS-2971
> URL: https://issues.apache.org/jira/browse/TS-2971
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Affects Versions: 5.1.1
>Reporter: Miles Libbey
>Assignee: Miles Libbey
> Fix For: 5.1.0
>
>
> The authproxy plugin has a debug tag of AuthProxy.  Most (all?) plugins use 
> their name as the debug symbol. Consistency makes it easier to debug, 
> especially in a complex interaction plugin like authproxy.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (TS-2977) move traffic_manager under cmd subdirectory

2014-07-30 Thread James Peach (JIRA) 
James Peach created TS-2977:
---

 Summary: move traffic_manager under cmd subdirectory
 Key: TS-2977
 URL: https://issues.apache.org/jira/browse/TS-2977
 Project: Traffic Server
  Issue Type: Task
  Components: Cleanup
Reporter: James Peach


The management code is pretty complicated and hard to understand. Separating 
traffic_manager out under the cmd/ subdirectory will give a clearer separation 
between the management library code and the application, and make it consistent 
with the rest of the tooling.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TS-2977) move traffic_manager under cmd subdirectory

2014-07-30 Thread Leif Hedstrom (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2977:
--

Fix Version/s: 5.1.0

> move traffic_manager under cmd subdirectory
> ---
>
> Key: TS-2977
> URL: https://issues.apache.org/jira/browse/TS-2977
> Project: Traffic Server
>  Issue Type: Task
>  Components: Cleanup
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.1.0
>
>
> The management code is pretty complicated and hard to understand. Separating 
> traffic_manager out under the cmd/ subdirectory will give a clearer 
> separation between the management library code and the application, and make 
> it consistent with the rest of the tooling.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TS-2977) move traffic_manager under cmd subdirectory

2014-07-30 Thread Leif Hedstrom (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2977:
--

Issue Type: Improvement  (was: Task)

> move traffic_manager under cmd subdirectory
> ---
>
> Key: TS-2977
> URL: https://issues.apache.org/jira/browse/TS-2977
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cleanup
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.1.0
>
>
> The management code is pretty complicated and hard to understand. Separating 
> traffic_manager out under the cmd/ subdirectory will give a clearer 
> separation between the management library code and the application, and make 
> it consistent with the rest of the tooling.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TS-2977) move traffic_manager under cmd subdirectory

2014-07-30 Thread Leif Hedstrom (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2977:
--

Assignee: James Peach

> move traffic_manager under cmd subdirectory
> ---
>
> Key: TS-2977
> URL: https://issues.apache.org/jira/browse/TS-2977
> Project: Traffic Server
>  Issue Type: Task
>  Components: Cleanup
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.1.0
>
>
> The management code is pretty complicated and hard to understand. Separating 
> traffic_manager out under the cmd/ subdirectory will give a clearer 
> separation between the management library code and the application, and make 
> it consistent with the rest of the tooling.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2977) move traffic_manager under cmd subdirectory

2014-07-30 Thread Leif Hedstrom (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079972#comment-14079972
 ] 

Leif Hedstrom commented on TS-2977:
---

+1


> move traffic_manager under cmd subdirectory
> ---
>
> Key: TS-2977
> URL: https://issues.apache.org/jira/browse/TS-2977
> Project: Traffic Server
>  Issue Type: Task
>  Components: Cleanup
>Reporter: James Peach
> Fix For: 5.1.0
>
>
> The management code is pretty complicated and hard to understand. Separating 
> traffic_manager out under the cmd/ subdirectory will give a clearer 
> separation between the management library code and the application, and make 
> it consistent with the rest of the tooling.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2971) Authproxy plugin has inconsistent debug symbol

2014-07-30 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14080084#comment-14080084
 ] 

ASF subversion and git services commented on TS-2971:
-

Commit 7b1b931808a8a5eb9e0d396a5860fd55896729ae in trafficserver's branch 
refs/heads/master from [~mlibbey]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=7b1b931 ]

TS-2971 Added note to CHANGES


> Authproxy plugin has inconsistent debug symbol
> --
>
> Key: TS-2971
> URL: https://issues.apache.org/jira/browse/TS-2971
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Affects Versions: 5.1.1
>Reporter: Miles Libbey
>Assignee: Miles Libbey
> Fix For: 5.1.0
>
>
> The authproxy plugin has a debug tag of AuthProxy.  Most (all?) plugins use 
> their name as the debug symbol. Consistency makes it easier to debug, 
> especially in a complex interaction plugin like authproxy.



--
This message was sent by Atlassian JIRA
(v6.2#6252)