[jira] [Commented] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1
[ https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14077722#comment-14077722 ] Susan Hinrichs commented on TS-2954: I got the basic proxy client address verification support in yesterday. I plan on doing more tests today and some debug message cleanup and hope to have a patch for others to try out later today. One thing I observed in my testing so far. For domains with lots of addresses (like google.com, youtube,com, and i.ytimg.com), the servers only seem to return 10 or so addresses at a time. Working against the google public dns server (8.8.8.8), the set of 10 would vary over a broader set of one hundred or so. So it is quite likely (and I saw in my testing), that the client picks a valid addresses out of one set of addresses for google.com, but the proxy checks against another set of valid addresses for google.com and so marks the response as uncacheable. Not sure there is much to be done here. Once at item is cached, the mismatch won't matter. But with false mismatches between the client and the proxy DNS lookups, the number of requests to get an item into the cache will increase. One could consider tracking both a validation set and a current address set in hostDB. Old address sets are moved into the validation set and used only to specify client specified origin server addresses. Looking at +edns with dig, it doesn't seem that more IPs are returned in that case either. But I only did some very basic checks. It could well be that some DNS server do return more addresses with the EDNS support. When we rework the hostDB DNS caching logic, supporting EDNS should also be added. Any other ideas or suggestions? 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: Alan M. Carroll Priority: Critical 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] [Updated] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1
[ https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2954: Assignee: Susan Hinrichs (was: Alan M. Carroll) 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 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] [Issue Comment Deleted] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1
[ https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2954: Comment: was deleted (was: I will take a supervisory role on this, Susan will be doing the primary implementation.) 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 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] [Updated] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1
[ https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2954: Fix Version/s: 5.1.0 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 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] [Updated] (TS-2956) Add pre_ssl_accept hook for better plugin access to SSL handling.
[ https://issues.apache.org/jira/browse/TS-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2956: Assignee: Susan Hinrichs (was: Alan M. Carroll) Add pre_ssl_accept hook for better plugin access to SSL handling. - Key: TS-2956 URL: https://issues.apache.org/jira/browse/TS-2956 Project: Traffic Server Issue Type: Improvement Components: Core, Plugins, SSL Reporter: Susan Hinrichs Assignee: Susan Hinrichs Organizations that want to do more extensive SSL processing than is allowed by the core should be able to write a plugin. To support such plugins, the core needs to allow for the plugin to gain access after the TCP connection has completed but before the SSL Accept has completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2956) Add pre_ssl_accept hook for better plugin access to SSL handling.
[ https://issues.apache.org/jira/browse/TS-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2956: Priority: Minor (was: Major) Add pre_ssl_accept hook for better plugin access to SSL handling. - Key: TS-2956 URL: https://issues.apache.org/jira/browse/TS-2956 Project: Traffic Server Issue Type: Improvement Components: Core, Plugins, SSL Reporter: Susan Hinrichs Assignee: Susan Hinrichs Priority: Minor Fix For: 5.2.0 Organizations that want to do more extensive SSL processing than is allowed by the core should be able to write a plugin. To support such plugins, the core needs to allow for the plugin to gain access after the TCP connection has completed but before the SSL Accept has completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2956) Add pre_ssl_accept hook for better plugin access to SSL handling.
[ https://issues.apache.org/jira/browse/TS-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2956: Fix Version/s: 5.2.0 Add pre_ssl_accept hook for better plugin access to SSL handling. - Key: TS-2956 URL: https://issues.apache.org/jira/browse/TS-2956 Project: Traffic Server Issue Type: Improvement Components: Core, Plugins, SSL Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 5.2.0 Organizations that want to do more extensive SSL processing than is allowed by the core should be able to write a plugin. To support such plugins, the core needs to allow for the plugin to gain access after the TCP connection has completed but before the SSL Accept has completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Issue Comment Deleted] (TS-2956) Add pre_ssl_accept hook for better plugin access to SSL handling.
[ https://issues.apache.org/jira/browse/TS-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2956: Comment: was deleted (was: Assigned to me, but Susan (shinrich) will be doing most of the work.) Add pre_ssl_accept hook for better plugin access to SSL handling. - Key: TS-2956 URL: https://issues.apache.org/jira/browse/TS-2956 Project: Traffic Server Issue Type: Improvement Components: Core, Plugins, SSL Reporter: Susan Hinrichs Assignee: Susan Hinrichs Organizations that want to do more extensive SSL processing than is allowed by the core should be able to write a plugin. To support such plugins, the core needs to allow for the plugin to gain access after the TCP connection has completed but before the SSL Accept has completed. -- 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
[ https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14077765#comment-14077765 ] Alan M. Carroll commented on TS-2954: - A potential approach to the caching problem is to proxy the DNS requests so that the client and ATS are in rough synchronization. This would be a rather significant change to ATS in its current form. However, the planned HostDB upgrade would make this much simpler as a different DNS server could be used per deployment instance. This would have two big advantages - (1) only deployments that need it would have it and (2) a third party DNS recursive server could be used making keeping up with DNS related security issues much easier. 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 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] [Updated] (TS-2966) Update Feature not working
[ https://issues.apache.org/jira/browse/TS-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Stinner updated TS-2966: --- Attachment: trafficserver.patch Update Feature not working -- Key: TS-2966 URL: https://issues.apache.org/jira/browse/TS-2966 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Thomas Stinner Attachments: trafficserver.patch I had a problem using the update feature. I recevied a SegFault in do_host_db_lookup which was caused by accessing ua_session which was not initialized (see attached patch). After fixing that i no longer get an SegFault, but the files that are retrieved by recursion are not placed into the cache. They are requested in every schedule. Only the starting file is placed correctly into the cache. When retrieving the files with a client, caching works as expected. So i don't think this is a configuration error. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2967) failed assert if ssl_multicert.config doesn't exist
Jack Bates created TS-2967:
--
Summary: 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] [Created] (TS-2966) Update Feature not working
Thomas Stinner created TS-2966: -- Summary: Update Feature not working Key: TS-2966 URL: https://issues.apache.org/jira/browse/TS-2966 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Thomas Stinner I had a problem using the update feature. I recevied a SegFault in do_host_db_lookup which was caused by accessing ua_session which was not initialized (see attached patch). After fixing that i no longer get an SegFault, but the files that are retrieved by recursion are not placed into the cache. They are requested in every schedule. Only the starting file is placed correctly into the cache. When retrieving the files with a client, caching works as expected. So i don't think this is a configuration error. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2966) Update Feature not working
[ https://issues.apache.org/jira/browse/TS-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Stinner updated TS-2966: --- Attachment: traffic.out Update Feature not working -- Key: TS-2966 URL: https://issues.apache.org/jira/browse/TS-2966 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Thomas Stinner Attachments: traffic.out, trafficserver.patch I had a problem using the update feature. I recevied a SegFault in do_host_db_lookup which was caused by accessing ua_session which was not initialized (see attached patch). After fixing that i no longer get an SegFault, but the files that are retrieved by recursion are not placed into the cache. They are requested in every schedule. Only the starting file is placed correctly into the cache. When retrieving the files with a client, caching works as expected. So i don't think this is a configuration error. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2968) CLONE - Make proxy.config.http.doc_in_cache_skip_dns overridable
[ https://issues.apache.org/jira/browse/TS-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2968: -- Fix Version/s: 5.1.0 CLONE - Make proxy.config.http.doc_in_cache_skip_dns overridable Key: TS-2968 URL: https://issues.apache.org/jira/browse/TS-2968 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.1.0 Make this overridable per remap rule / plugin. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2968) CLONE - Make proxy.config.http.doc_in_cache_skip_dns overridable
[ https://issues.apache.org/jira/browse/TS-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2968: -- Labels: A (was: ) CLONE - Make proxy.config.http.doc_in_cache_skip_dns overridable Key: TS-2968 URL: https://issues.apache.org/jira/browse/TS-2968 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 5.1.0 Make this overridable per remap rule / plugin. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2968) CLONE - Make proxy.config.http.doc_in_cache_skip_dns overridable
[ https://issues.apache.org/jira/browse/TS-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14077984#comment-14077984 ] Leif Hedstrom commented on TS-2968: --- Yeah, this is b0rken, I have a patch proposal. CLONE - Make proxy.config.http.doc_in_cache_skip_dns overridable Key: TS-2968 URL: https://issues.apache.org/jira/browse/TS-2968 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 5.1.0 Make this overridable per remap rule / plugin. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Work started] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1
[ https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TS-2954 started by Susan Hinrichs. 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 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-2967) failed assert if ssl_multicert.config doesn't exist
[
https://issues.apache.org/jira/browse/TS-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14078495#comment-14078495
]
James Peach commented on TS-2967:
-
I think the best bet is to just remove the asserts. I think there's only one
place that uses {{SSLCertificateConfig::scoped_config}} that uses the config
without a check.
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] [Commented] (TS-2802) Add SNI support for origin servers
[
https://issues.apache.org/jira/browse/TS-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14078688#comment-14078688
]
James Peach commented on TS-2802:
-
Looks good. Will merge tomorrow.
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] [Assigned] (TS-2802) Add SNI support for origin servers
[
https://issues.apache.org/jira/browse/TS-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reassigned TS-2802:
---
Assignee: James Peach (was: Bryan Call)
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] [Work stopped] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1
[ https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TS-2954 stopped by Susan Hinrichs. 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 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] [Updated] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1
[ https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2954: --- Attachment: ts-2954.patch [~ngorchilov] could you take a look at the patch and give it a test? 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-2860) AArch64 support
[ https://issues.apache.org/jira/browse/TS-2860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14078760#comment-14078760 ] Phil Sorber commented on TS-2860: - [~hrw-redhat], We are planning to include [Concurrency Kit|http://concurrencykit.org/] in ATS to handle atomics and concurrent data structures. Can you port CK to ARM64 as well? Or provide access to an ARM64 host so that we can attempt? Thanks. 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)
