Re: records.config to records.yaml

[SUSAN HINRICHS]

Single format is fine with me as long as start up will fail if there is no
records.yaml and there is an old style records.config present. As I recall
in the ipallow upgrade it would just go with defaults. That caused a number
of us a day or so debugging.

On Thu, Sep 22, 2022, 10:50 AM Sudheer Vinukonda
 wrote:

>  My vote is for #2 (ie support a single format), but, if possible, it'd be
> great if we can automatically convert the existing config files into YAML
> as part of the upgrade. At the very least, we should provide a tool + steps
> on how to convert even if it's manual.
> On Thursday, September 22, 2022 at 08:42:35 AM PDT, Damian Meden <
> dme...@apache.org> wrote:
>
>  Hello guys,  as a part of the moving to yaml, I plan to work on converting
> our records.config to records.yaml, this has been going on for a while now
> so hopefully I can get some traction now.
> As a *phase 1* of this task and aiming for 10 release, the plan is just to
> keep the original librecord internals and just have a yaml parsing layer to
> fill in the existing records similar to the current process but having the
> records.yaml as input file.
> Now after having some talks with some of you separately one think came up
> in common:
>
>
>   1. Do we want to have dual parsing, like we did with ip_allow.yaml or:
>   2. Single yaml parsing and ask everyone to just convert to yaml for 10
>   release.
>
>
> More details about the records.yaml I put together some time ago can be
> found here  and for a
> quick look at how the records.yaml would look like, check here
> .
>
>
> Any feedback will be appreciated.
>
> Thanks,
> Damian.
> Yahoo
>

Re: [E] Installation error from GIT

[Susan Hinrichs]

We are using systemd to start the service in our environment.  There
is a starter service file in the rc directory.

On Wed, May 26, 2021 at 10:23 AM Alan Carroll
 wrote:
>
> I'm not sure what you mean. There are scripts in the "bin" directory of the 
> installation that start and stop the processes.  E.g. "bin/trafficserver 
> start" will start ATS and "bin/trafficserver stop" will stop it. The primary 
> process to start/top is "bin/traffic_manager". This will spawn the 
> "traffic_server" process which does the actual proxying. Unfortunately I do 
> not do much production engineering and am not very familiar with how to run 
> it in production (I run it using "gdb traffic_server" but that's probably not 
> a good idea for normal use). You might trying pinging some of the production 
> engineers on the slack channel.
>
> On Wed, May 26, 2021 at 7:28 AM Trilok Nathreddy  wrote:
>>
>> Alan,
>>
>> Many thanks that fixed the issue , I have deployed now the Ats 10 version on 
>> RHEL instance , just curious under which directory we need to 
>> start/stop/restart the services for traffic server? I look under 
>> /opt/ts/etc/trafficserver but couldn't find them
>>
>>
>>
>> On Tue, May 25, 2021, 7:01 PM Alan Carroll 
>>  wrote:
>>>
>>> This means there is no C++ compiler installed. Please see the list of 
>>> required packages at 
>>> https://docs.trafficserver.apache.org/en/9.0.x/getting-started/index.en.html#installing-from-source-code
>>>
>>>

Re: [E] Re: [VOTE] Release Apache Traffic Server 9.0.1 (RC1)

[Susan Hinrichs]

+1

Synced and running in production.

On Mon, Apr 12, 2021 at 2:55 PM Randall Meyer
 wrote:
>
>  +1
>  On Saturday, April 10, 2021, 03:21:58 PM PDT, Leif Hedstrom 
>  wrote:
>
>  I've prepared a another release for 9.0.1 (RC1), which is a bug fix release 
> only. For a list of all PRs, see
>
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_trafficserver_milestone_31-3Fclosed-3D1=DwIFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=GAqM_xZpxNbVqsR-aGvQBjOG3d33Y2-i4ynL-JkEouY=HGcYPSkSbfGRufs6aeP5Nwb-jKgnUtkj1_XAfATQeCk=gl5sTFTJZwKLTSrTb-q4rqkU_BNR22GHKCuz-oQC1Mw=
>
>
> or for a brief ChangeLog (also attached below):
>
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_trafficserver_blob_9.0.x_CHANGELOG-2D9.0.1=DwIFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=GAqM_xZpxNbVqsR-aGvQBjOG3d33Y2-i4ynL-JkEouY=HGcYPSkSbfGRufs6aeP5Nwb-jKgnUtkj1_XAfATQeCk=-iWe7JT4uDvW_BYDohKliw-XYFNXgKjHUdKRKeu8WAg=
>
>
> This release of v9.0.1 is backwards compatible with the v9.0.0 release, for 
> some details as to what was new in v9.0.x see
>
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.trafficserver.apache.org_en_9.0.x_release-2Dnotes_whats-2Dnew.en.html=DwIFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=GAqM_xZpxNbVqsR-aGvQBjOG3d33Y2-i4ynL-JkEouY=HGcYPSkSbfGRufs6aeP5Nwb-jKgnUtkj1_XAfATQeCk=qWA_e36YurvM_ZcOF4BQ8IMqbOdssr0mrOohD5Ir9YQ=
>
>
> The artifacts are available for download at:
>
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__people.apache.org_-7Ezwoop_rel-2Dcandidates_9.0.1-2Drc1_=DwIFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=GAqM_xZpxNbVqsR-aGvQBjOG3d33Y2-i4ynL-JkEouY=HGcYPSkSbfGRufs6aeP5Nwb-jKgnUtkj1_XAfATQeCk=CsLQnjtY4gBEbH6TBC3J-VN4yW7ybtDow23DGYgJ5H8=
>
>
> SHA512 checksum: 
> 74eca6522c880b13e4ca7aca0f73c9252e84778a26027b1fb21f3e5f81eadedba884347f4e75cc6bd6778945bbf2e3f0b17543ae92aba9e1941e2d797c14df1c
>  *trafficserver-9.0.1-rc1.tar.bz2
>
>
> This corresponds to git refs:
>
> Hash: 3bb1ae9fa5c71b8e65cb782f402d8780b522693d
> Tag: 9.0.1-rc1
>
>
> Which can be verified with the following command:
>
> $ git tag -v 9.0.1-rc1
>
>
> All code signing keys are available here:
>
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__dist.apache.org_repos_dist_dev_trafficserver_KEYS=DwIFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=GAqM_xZpxNbVqsR-aGvQBjOG3d33Y2-i4ynL-JkEouY=HGcYPSkSbfGRufs6aeP5Nwb-jKgnUtkj1_XAfATQeCk=fRGvlr64HU4UTwPYoD8uYnnJRC_MsBpg76Vr24k4DOQ=
>
>
> Make sure you refresh from a key server to get all relevant signatures. This 
> vote is open until EOB April 14th, but please test and cast your votes as 
> early as possible.
>
> Cheers,
>
> — Leif
>
> Changes with Apache Traffic Server 9.0.1
>   #3871 - Fix heap use after free in DNSProcessor::getby()
>   #6302 - Simple and miscellaneous fixes/additions for lua plugin
>   #6691 - Slice plugin: self heal when asset etag/last-modified block 
> mismatches
>   #6780 - Use Proxy-Connection iff parent_is_proxy=true
>   #6860 - Make format specifier for time_t portable
>   #6893 - AuTest: Pipfile update to use microserver 1.0.5
>   #6919 - slice: clean up 502 header/body generation.
>   #7064 - CacheRead: clear dir entry if doc is found to be truncated
>   #7158 - Fix lua plugin mem leak problem
>   #7257 - slice: default to throttling, fixes to manufactured 416 responses.
>   #7259 - detect and fix stms log field having epoch time ms for intercept 
> plugins.
>   #7287 - option to disable compression for range request's response
>   #7288 - Adjust to actually try a server address more than once
>   #7309 - Disable client inactivity timeout while server is processing POST 
> request
>   #7347 - Allow for regex_remap of pristine URL.
>   #7368 - Cleanup: Remove SSL Wire Trace releated code in UnixNetVConnection
>   #7377 - Addresses some of the lock contention with HostStatus.
>   #7395 - Replace ::exit() with _exit() to avoid secondary cleanup cores
>   #7410 - Fix issue with unavailable server retry codes
>   #7414 - Remove the warning messages
>   #7415 - Fix the Proxy Verifier AuTest extension to handle cert paths 
> correctly
>   #7416 - Enhancements for compress plugin
>   #7420 - Update documentation for TSSslSessionInsert
>   #7421 - Change comment handling for long lines in url_sig plugin
>   #7422 - Do not provide a stale negative cache
>   #7432 - Fix stall on outbound TLS handshake
>   #7435 - Slice: 9.0.x back port of self healing and throttle by default
>   #7437 - Small fix to regex_remap PR # 7347.
>   #7443 - Change squid log code for self looping
>   #7454 - Updating to Proxy Verifier v2.0.0
>   #7460 - Update to the new MicroServer 1.0.6 release
>   #7463 - Fixing compress expectation for new microserver
>   #7468 - Proxy Verifier: Making use of delay directives for caching tests.
>   #7469 - Update AuTest version update directions for pipenv
>   #7483 - Fix KA header not checking strategy
>   #7484 - traffic_ctl - Fix 

Re: [E] Passing ftp, ftps etc. to Squid?

[Susan Hinrichs]

My understanding is that the FTP proxy support in ATS was removed some
time back, so you will need to route your ftp traffic to another
proxy.

I can think of three options
1.  Use a different DNS name to resolve to the address of your FTP proxy.
2.  Run your FTP proxy on the same machine as ATS.  The OS will
deliver your port 21 traffic to the FTP proxy.
3. Use the DNAT action of iptables to forward FTP packets that arrive
on your ATS box to the address of your FTP proxy server.

On Sun, Apr 11, 2021 at 11:13 AM Randy DuCharame  wrote:
>
> Greetings,
>
> I seem to be stuck.  I'm always using the latest from 'master' and
> almost never have problems with it.  The problem I'm having is between
> my ears LOL.  I can't seem to figure out how to get ATS to hand off
> forward ftp, ftps, sftp requests to Squid.  I've not found the 'magic
> sauce' to get ATS to proxy these protocols itself (yet) so am wondering
> if someone can help - or at least point me in the right direction.  ATS
> is so much faster with http/https so I don't want to switch back to
> Squid outright.  Normally for me, the usual RTFM exercise solves
> problems such as this but I'm gettin' old and the firmware is beginning
> to experience bit rot I'm afraid.  (It sucks to get old people.
> Don't
> do it!)  :D
>
> Many TIA for any pointers.
>
> --
> Randall DuCharme (Radio AD5GB)
> Powered by Open Source software.
>

Re: [E] Unable to use ATS 7.1.1 with openssl 1.1.1

[Susan Hinrichs]

I'm sorry, I haven't seen that crash.  But I haven't run on the base
7.1.x branch for several years and not with openssl 1.1.1 code.  I
poked around the openssl code and based on the line numbers, it looks
like the v->get_cert_methods method in X509_STORE_add_lookup is
getting messed up.  This is ultimately called from
SSL_CTX_load_verify_locations or X509_STORE_load_locations directly.
I don't think our calls into this have changed from 7.1.x through to
our current master/10.x branch.  So it is unclear what the problem
would be with introducing openssl 1.1.1

What version of openssl 1.1.1 are you using?  Did this work if you ran
it against 1.0.2?  I know that a number of folks are running the 8.0.x
and 8.1.x builds against openssl 1.1.1. You might try moving forward
with ATS.

On Fri, Apr 9, 2021 at 7:26 AM supraja sridhar
 wrote:
>
> Hi,
>
> When I try to send traffic to  ATS 7.1.1 with the system having openssl 1.1.1 
> I am seeing the below crash. Can someone help identify the issue ?
>
> [Thread debugging using libthread_db enabled]
>
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>
> Core was generated by `trafficserver'.
>
> Program terminated with signal SIGSEGV, Segmentation fault.
>
> #0 X509_STORE_add_lookup (v=v@entry=0x7fabe84da600, m=0x7fabf6808620 
> ) at crypto/x509/x509_lu.c:254
>
> [Current thread is 1 (Thread 0x7fabf42a3700 (LWP 17522))]
>
> #0 X509_STORE_add_lookup (v=v@entry=0x7fabe84da600, m=0x7fabf6808620 
> ) at crypto/x509/x509_lu.c:254
>
> #1 0x7fabf653749d in X509_STORE_load_locations (ctx=0x7fabe84da600, 
> file=0x5654faa23130 "/etc/ssl_ca/canonical_ca_roots.pem", path=0x5654faa23110 
> "/etc/ssl_ca/") at crypto/x509/x509_d2.c:48
>
> #2 0x5654f85b97de in SSLNetVConnection::sslStartHandShake 
> (this=0x7fabec4b9840, event=1, err=@0x7fabf42a2cd8: -197496816) at 
> /workspace/trafficserver/iocore/net/SSLNetVConnection.cc:1005
>
> #3 0x5654f85d48dd in write_to_net_io (nh=0x7fabf43aae60, 
> vc=0x7fabec4b9840, thread=0x7fabf43a7010) at 
> /workspace/trafficserver/iocore/net/UnixNetVConnection.cc:446
>
> #4 0x5654f85d47c1 in write_to_net (nh=0x7fabf43aae60, vc=0x7fabec4b9840, 
> thread=0x7fabf43a7010) at 
> /workspace/trafficserver/iocore/net/UnixNetVConnection.cc:424
>
> #5 0x5654f85ca98e in NetHandler::mainNetEvent (this=0x7fabf43aae60, 
> event=5, e=0x5654fa8c2ca0) at 
> /workspace/trafficserver/iocore/net/UnixNet.cc:516
>
> #6 0x5654f8349d0c in Continuation::handleEvent (this=0x7fabf43aae60, 
> event=5, data=0x5654fa8c2ca0) at 
> /workspace/trafficserver/iocore/eventsystem/I_Continuation.h:153
>
> #7 0x5654f85f7225 in EThread::process_event (this=0x7fabf43a7010, 
> e=0x5654fa8c2ca0, calling_code=5) at 
> /workspace/trafficserver/iocore/eventsystem/UnixEThread.cc:143
>
> #8 0x5654f85f772b in EThread::execute (this=0x7fabf43a7010) at 
> /workspace/trafficserver/iocore/eventsystem/UnixEThread.cc:270
>
> #9 0x5654f85f68c3 in spawn_thread_internal (a=0x5654fa892810) at 
> /workspace/trafficserver/iocore/eventsystem/Thread.cc:84
>
> #10 0x7fabf61406ba in start_thread () from 
> /lib/x86_64-linux-gnu/libpthread.so.0
>
> #11 0x7fabf53d16cd in clone () from /lib/x86_64-linux-gnu/libc.so.6
>
>
> Thanks,
>
> Supraja

Re: [E] ssllabs test fails : Assessment failed: String index out of range: 130

[Susan Hinrichs]

What version of ATS are you running?  Our production servers running
9.0 are scanned without problem.


On Thu, Mar 11, 2021 at 3:44 PM juergenp  wrote:
>
> Hello,
>
> did anyone also get such errors ?
>
>
>
> i tried ssl-test through ATS and afterwards directly on nginx/apache
>
> each try with ATS fails with: Assessment failed: String index out of range:
> 130  or 140
> nginx native works.
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ssllabs.com_ssltest_analyze.html=DwICAg=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=Ct9BRY8473_NWxRBvSW0ZOHBpyExcu9qgij7MorbZuA=NMXZd75TNUzTYtJeVJA67TZPX9wgQLC3ci9UE4pR9yo=cIj_H6R15yVX1iafvDi-s18vmxK2SNPEd-5qGwNP1Zc=
>
> kr
>
> Juergen
>
>
>
> --
> Sent from: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__apache-2Dtraffic-2Dserver.24303.n7.nabble.com_=DwICAg=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=Ct9BRY8473_NWxRBvSW0ZOHBpyExcu9qgij7MorbZuA=NMXZd75TNUzTYtJeVJA67TZPX9wgQLC3ci9UE4pR9yo=FObJ4NYrz7oGJZNcEGc864s27ymP6xs5QU5QJLbLwn8=

Re: [E] Some disconnections from origin

[Susan Hinrichs]

At a quick glance, your settings seem reasonable.  Judging from the debug
output you shared, I'd suggest looking at your origin.  Based on the debug
output, ATS successfully makes a connection to the origin and thinks it
sends the request (doesn't necessarily means the origin has processed the
request just that the request has been passed to the networking stack), and
then the origin closes the connection (sends an EOS/FIN/RST).  Is your
connection to origin TLS or just plain TCP?   If it is just plain TCP, the
OS will deal with the handshake for the most part even if your origin app
is overloaded.

Looking at the timestamps, it looks like the origin responds with an EOS
very quickly, so it doesn't seem to be a timeout issue on the origin.  A
packet capture between ATS and the origin, may verify that the origin is
indeed initiating the connection close.

Susan

On Tue, Jan 12, 2021 at 3:20 AM Łukasz Nowak  wrote:

> Hello,
>
> I am using TrafficServer which has only one origin - haproxy - and which
> serves as a cache for many sites.
>
> Details are:
>
> Version of Traffic Server used: 7.1.12 (also applies to 8.1.0)
> Platform: Linux 64 bit, gcc 8.3.0
> Any relevant configuration changes you've made from the default
> configurations (particularly for records.config), part of `traffic_ctl
> diff`:
> proxy.config.http.cache.open_write_fail_action has changed
> Current Value   : 2
> Default Value   : 0
> proxy.config.http.negative_revalidating_enabled has changed
> Current Value   : 1
> Default Value   : 0
> proxy.config.http.negative_revalidating_lifetime has changed
> Current Value   : 86400
> Default Value   : 1800
> proxy.config.http.insert_client_ip has changed
> Current Value   : 0
> Default Value   : 1
> proxy.config.http.insert_squid_x_forwarded_for has changed
> Current Value   : 0
> Default Value   : 1
> proxy.config.http.transaction_no_activity_timeout_in has changed
> Current Value   : 600
> Default Value   : 30
> proxy.config.http.transaction_no_activity_timeout_out has changed
> Current Value   : 600
> Default Value   : 30
> proxy.config.http.connect_attempts_max_retries has changed
> Current Value   : 0
> Default Value   : 3
> proxy.config.http.connect_attempts_max_retries_dead_server has changed
> Current Value   : 0
> Default Value   : 1
> proxy.config.http.connect_attempts_timeout has changed
> Current Value   : 600
> Default Value   : 30
> proxy.config.http.post_connect_attempts_timeout has changed
> Current Value   : 600
> Default Value   : 1800
> proxy.config.http.normalize_ae_gzip has changed
> Current Value   : 0
> Default Value   : 1
> proxy.config.cache.ram_cache.size has changed
> Current Value   : 1073741824
> Default Value   : -1
> proxy.config.url_remap.pristine_host_hdr has changed
> Current Value   : 1
> Default Value   : 0
>
> I have trafficserver connecting to origin (haproxy) on the same host with:
>
> cat etc/trafficserver/remap.config
> map /HTTPS/ http://10.0.251.170:21443
> 
> map / http://10.0.251.170:41080
> 
>
> There is constant stream of requests going to trafficserver. About 0.5% of
> them fails with returning 502 to the client, with entry in
> var/log/trafficserver/error.log:
>
> 20210107.13h02m15s CONNECT: could not connect to 10.0.251.170 for '
> http://10.0.251.170:41080/path/
> '
> (setting last failure time)
> 20210107.13h02m15s RESPONSE: sent 10.0.251.170 status 502 (Server Hangup)
> for 'http://10.0.251.170:41080/path/
> 
> '
>
> also seen in var/log/trafficserver/squid.log:
>
> 1610020935.756 43 10.0.251.170 TCP_REFRESH_FAIL_HIT/502 498 GET
> http://10.0.251.170:41080/path/
> 

Re: Client / TS certificates 7.x vs 8.x

[Susan Hinrichs]

/urldefense.proofpoint.com/v2/url?u=http-3A__sslnetvconnection.cc-3A1213=DwMFAg=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=Ct9BRY8473_NWxRBvSW0ZOHBpyExcu9qgij7MorbZuA=eMNTvVzsIr4oMX8X4S6-8igbwFdenlRaU7SzsGbsuN4=NeldsD4eLgkhoyTV-xMLLQXlHwznW8HxcVoSqwV9Xj0=>
> (sslServerHandShakeEvent)> (ssl-diag) SSL handshake error: SSL_ERROR_SSL
> (1), errno=0
> [Jan  6 08:21:22.636] {0x7ff241b10700} DEBUG:  <https://urldefense.proofpoint.com/v2/url?u=http-3A__sslnetvconnection.cc-3A1339=DwMFAg=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=Ct9BRY8473_NWxRBvSW0ZOHBpyExcu9qgij7MorbZuA=eMNTvVzsIr4oMX8X4S6-8igbwFdenlRaU7SzsGbsuN4=5R00uQMyJ9YmmMafXRE9xHQzKiK1yEVJf-X57vJ0jGg=>
> (sslServerHandShakeEvent)> (ssl-diag)
> SSLNetVConnection::sslServerHandShakeEvent, SSL_ERROR_SSL errno=0
>
>
> The certificate is quite old but valid.
> Validity
>     Not Before: Aug 18 14:29:55 2017 GMT
> Not After : Aug 16 14:29:55 2027 GMT
>
> There is nothing noteworthy in diags.log nor any startup errors or
> warnings.
>
> Thanks again,
> Zack
>
>
>
> On Jan 6, 2021, at 7:38 AM, Susan Hinrichs 
> wrote:
>
> The config looks good to me.   There are autests that exercise ATS
> requiring certs from the client with a variety of CA verification
> configurations.  I haven't worked with the 8.x branch, but those tests are
> run against that branch I believe.
>
> Is your client certificate directly signed by the certificate in ca.pem?
> Is there an intermediate cert floating around someplace?  Assuming the
> certs are exchanged as in the working case, it seems likely that the
> failure is occurring in the client certificate verification.  I assume that
> ATS is sending the SSL alert.
>
> Any interesting start up failure messages in diags.log?
>
> The next thing to check is turning on debugging and setting the ssl debug
> tag.
>
> On Tue, Jan 5, 2021 at 4:49 PM Zack Bartel  wrote:
>
>> Hello,
>> We are using client -> TS SSL termination and using client certificates
>> and a CA. While upgrading to 8.x this has stopped working and I'm having
>> trouble figuring out why. I was wondering if there may have been some
>> change in 8.x or error with my config  which would be obvious to someone.
>>
>> The error is "SSL alert number 80" internal error.
>>
>> SSL_connect:SSLv3/TLS read server certificate request
>> SSL_connect:SSLv3/TLS read server done
>> SSL_connect:SSLv3/TLS write client certificate
>> SSL_connect:SSLv3/TLS write client key exchange
>> SSL_connect:SSLv3/TLS write certificate verify
>> SSL_connect:SSLv3/TLS write change cipher spec
>>
>>
>> SSL_connect:SSLv3/TLS write finished
>> read from 0x564393d04170 [0x564393d0e6a3] (5 bytes => 5 (0x5))
>>  - 15 03 03 00 02.
>> read from 0x564393d04170 [0x564393d0e6a8] (2 bytes => 2 (0x2))
>>  - 02 50 .P
>>
>> *SSL3 alert read:fatal:internal error*
>> *SSL_connect:error in error*
>> *139713745085760:error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert
>> internal error:../ssl/record/rec_layer_s3.c:1543:SSL alert number 80*
>>
>>
>>
>> I've inspected the traffic with Wireshark to confirm the exchange is
>> identical between the versions up until the "Internal Error" response.
>> Tried up to 7.1.12-rc0 which works and 8.0.0 -> 8.1.x which does not. I've
>> also tried on Ubuntu and Centos8 with the same results.
>>
>> Relevant config:
>>
>>
>> records.config:
>> CONFIG proxy.config.ssl.CA.cert.path STRING /ssl/
>> CONFIG proxy.config.ssl.CA.cert.filename STRING ca.pem
>>
>> CONFIG proxy.config.ssl.client.verify.server INT 1
>> CONFIG proxy.config.ssl.client.certification_level INT 2
>> CONFIG proxy.config.ssl.client.CA.cert.path STRING /etc/pki/tls/certs/
>> CONFIG proxy.config.ssl.client.CA.cert.filename STRING ca-bundle.crt
>>
>> CONFIG proxy.config.ssl.client.cipher_suite STRING
>> TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:DES-CBC3-SHA
>>
>> CONFIG proxy.config.ssl.server.private_key.path STRING /ssl/
>> CONFIG proxy.config.ssl.server.cert.path STRING /ssl/
>>
>> CONFIG proxy.config.ssl.server.cipher_suite STRING
>> ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RS

Re: Client / TS certificates 7.x vs 8.x

[Susan Hinrichs]

The config looks good to me.   There are autests that exercise ATS
requiring certs from the client with a variety of CA verification
configurations.  I haven't worked with the 8.x branch, but those tests are
run against that branch I believe.

Is your client certificate directly signed by the certificate in ca.pem?
Is there an intermediate cert floating around someplace?  Assuming the
certs are exchanged as in the working case, it seems likely that the
failure is occurring in the client certificate verification.  I assume that
ATS is sending the SSL alert.

Any interesting start up failure messages in diags.log?

The next thing to check is turning on debugging and setting the ssl debug
tag.

On Tue, Jan 5, 2021 at 4:49 PM Zack Bartel  wrote:

> Hello,
> We are using client -> TS SSL termination and using client certificates
> and a CA. While upgrading to 8.x this has stopped working and I'm having
> trouble figuring out why. I was wondering if there may have been some
> change in 8.x or error with my config  which would be obvious to someone.
>
> The error is "SSL alert number 80" internal error.
>
> SSL_connect:SSLv3/TLS read server certificate request
> SSL_connect:SSLv3/TLS read server done
> SSL_connect:SSLv3/TLS write client certificate
> SSL_connect:SSLv3/TLS write client key exchange
> SSL_connect:SSLv3/TLS write certificate verify
> SSL_connect:SSLv3/TLS write change cipher spec
>
>
> SSL_connect:SSLv3/TLS write finished
> read from 0x564393d04170 [0x564393d0e6a3] (5 bytes => 5 (0x5))
>  - 15 03 03 00 02.
> read from 0x564393d04170 [0x564393d0e6a8] (2 bytes => 2 (0x2))
>  - 02 50 .P
>
> *SSL3 alert read:fatal:internal error*
> *SSL_connect:error in error*
> *139713745085760:error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert
> internal error:../ssl/record/rec_layer_s3.c:1543:SSL alert number 80*
>
>
>
> I've inspected the traffic with Wireshark to confirm the exchange is
> identical between the versions up until the "Internal Error" response.
> Tried up to 7.1.12-rc0 which works and 8.0.0 -> 8.1.x which does not. I've
> also tried on Ubuntu and Centos8 with the same results.
>
> Relevant config:
>
>
> records.config:
> CONFIG proxy.config.ssl.CA.cert.path STRING /ssl/
> CONFIG proxy.config.ssl.CA.cert.filename STRING ca.pem
>
> CONFIG proxy.config.ssl.client.verify.server INT 1
> CONFIG proxy.config.ssl.client.certification_level INT 2
> CONFIG proxy.config.ssl.client.CA.cert.path STRING /etc/pki/tls/certs/
> CONFIG proxy.config.ssl.client.CA.cert.filename STRING ca-bundle.crt
>
> CONFIG proxy.config.ssl.client.cipher_suite STRING
> TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:DES-CBC3-SHA
>
> CONFIG proxy.config.ssl.server.private_key.path STRING /ssl/
> CONFIG proxy.config.ssl.server.cert.path STRING /ssl/
>
> CONFIG proxy.config.ssl.server.cipher_suite STRING
> ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
>
> ssl_multicert.config:
> ssl_cert_name=server.pem
>
>
> Any help on this greatly appreciated, thank you,
>
> Zack
>

Re: [E] Force trafficserver to TLSv1.3

[Susan Hinrichs]

The post_handhake_auth is not wired into ATS yet.  Please file an issue
and/or put up a PR.

Susan

On Fri, Dec 11, 2020 at 12:54 AM  wrote:

> Yes, of course I have.
>
> CONFIG proxy.config.ssl.client.cert.path STRING /etc/ssl/certs/
> CONFIG proxy.config.ssl.client.cert.filename STRING xxx.pem
>
> CONFIG proxy.config.ssl.client.CA.cert.path STRING /etc/ssl/certs/
> CONFIG proxy.config.ssl.client.CA.cert.filename STRING xxx_CA.pem
>
> Question is if ATS is able send verify_client_post_handshake as extension
> in TLS Client Hello.
> Contrary if ATS do not send "post_handshake_auth" extension  then
> according to RFC 8446
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8446=DwMFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=GAqM_xZpxNbVqsR-aGvQBjOG3d33Y2-i4ynL-JkEouY=dHiiPqkyyHSl-9b3vx4X8tOb71wAdz3SNhxib3Tauyg=6Q5EKRjUtEXxv8fI9KLh89HQ5GAttKLWqVHzpke5NIc=>
> :
>
> The "post_handshake_auth" extension is used to indicate that a client
>is willing to perform post-handshake authentication (Section 4.6.2 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8446-23section-2D4.6.2=DwMFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=GAqM_xZpxNbVqsR-aGvQBjOG3d33Y2-i4ynL-JkEouY=dHiiPqkyyHSl-9b3vx4X8tOb71wAdz3SNhxib3Tauyg=UaAaGrnlwZ93nZ_vsBQXTPCWYegpOTWhdMVL3BciksU=>).
>Servers MUST NOT send a post-handshake CertificateRequest to clients
>which do not offer this extension. Servers MUST NOT send this extension.
>
>
>
> On Thu, Dec 10, 2020 at 5:48 PM Susan Hinrichs 
> wrote:
>
>> Sounds like the origin is requesting a client certificate which ATS is
>> not providing.
>>
>> Do you have your ATS configured to specify a client certificate if the
>> origin requests one?  This can be configured by the records.config setting
>> proxy.config.ssl.client.cert.filename (and related) These settings can also
>> be overridden on a per remap basis by using conf_remap.so.
>>
>> https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html?#proxy-config-ssl-client-cert-filename
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.trafficserver.apache.org_en_latest_admin-2Dguide_files_records.config.en.html-3F-23proxy-2Dconfig-2Dssl-2Dclient-2Dcert-2Dfilename=DwMFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=GAqM_xZpxNbVqsR-aGvQBjOG3d33Y2-i4ynL-JkEouY=dHiiPqkyyHSl-9b3vx4X8tOb71wAdz3SNhxib3Tauyg=2sCMMIzJ0LCafkVukFlHimKew6Redksmb8Jd30eiGuM=>
>>
>>
>> On Thu, Dec 10, 2020 at 7:17 AM  wrote:
>>
>>> Hi,
>>> I found a explanation how Wireshark presents TLSv1.3 and it seems my
>>> configuration is OK and TLSv1.3 is used.
>>>
>>> However I have another problem with origin server.
>>> It send me bag "403 Forbidden" because of :
>>>
>>> SSL Library Error: error:14268117:SSL
>>> routines:SSL_verify_client_post_handshake:extension not received
>>>
>>>
>>> As I understand ATS do not send  in Client Hello
>>> "verify_client_post_handshake " extension.
>>>
>>> Is it possible to configure somehow?
>>>
>>>
>>> Thanks Peter
>>>
>>

Re: [E] Force trafficserver to TLSv1.3

[Susan Hinrichs]

Sounds like the origin is requesting a client certificate which ATS is not
providing.

Do you have your ATS configured to specify a client certificate if the
origin requests one?  This can be configured by the records.config setting
proxy.config.ssl.client.cert.filename (and related) These settings can also
be overridden on a per remap basis by using conf_remap.so.
https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html?#proxy-config-ssl-client-cert-filename


On Thu, Dec 10, 2020 at 7:17 AM  wrote:

> Hi,
> I found a explanation how Wireshark presents TLSv1.3 and it seems my
> configuration is OK and TLSv1.3 is used.
>
> However I have another problem with origin server.
> It send me bag "403 Forbidden" because of :
>
> SSL Library Error: error:14268117:SSL
> routines:SSL_verify_client_post_handshake:extension not received
>
>
> As I understand ATS do not send  in Client Hello
> "verify_client_post_handshake " extension.
>
> Is it possible to configure somehow?
>
>
> Thanks Peter
>

Re: [UPDATED: RC1] Re: [E] [VOTE] Release Apache Traffic Server 9.0.0 (RC0)

[Susan Hinrichs]

+1

Ran autests and unit tests successfully.  Has been running in our
production environment on a machine for over an hour so far without
incident.

On Wed, Dec 9, 2020 at 10:23 AM Chou, Peter  wrote:

> Regression tests -R2 passed with Ubuntu Linux 18.04 LTS 64-bit server.
> Thanks.
>
> -Original Message-
> From: Leif Hedstrom 
> Sent: Tuesday, December 8, 2020 10:30 AM
> To: users 
> Cc: dev 
> Subject: [UPDATED: RC1] Re: [E] [VOTE] Release Apache Traffic Server 9.0.0
> (RC0)
>
> We’ll cancel the 9.0.0-RC0 candidate, and I’ve prepared a new 9.0.0-RC1
> candidate, now available for consumption at
>
>
> https://urldefense.com/v3/__https://people.apache.org/*zwoop/rel-candidates/9.0.0-rc1/__;fg!!BhdT!z8VSKqhv7LB3HRgqyevwmCScfJUwFVJi_6sI5eGkJ2jKBfxgjFZRUXfS_oOvy48$
>
>
> This includes all the changes suggested for the RC0 release, as well as a
> couple of other changes. The ChangeLog has been updated accordingly, same
> links as before.
>
> Please cast your votes before EOB Friday 12/11.
>
> — leif & bryan
>
>
> https://urldefense.com/v3/__https://github.com/apache/trafficserver/blob/9.0.x/CHANGELOG-9.0.0__;!!BhdT!z8VSKqhv7LB3HRgqyevwmCScfJUwFVJi_6sI5eGkJ2jKBfxgjFZRUXfScIfDMmw$
>
> https://urldefense.com/v3/__https://github.com/apache/trafficserver/pulls?q=is*3Aclosed*is*3Apr*milestone*3A9.0.0__;JSslKyU!!BhdT!z8VSKqhv7LB3HRgqyevwmCScfJUwFVJi_6sI5eGkJ2jKBfxgjFZRUXfSjTPvg-U$
>
> https://urldefense.com/v3/__https://docs.trafficserver.apache.org/en/9.0.x/release-notes/whats-new.en.html__;!!BhdT!z8VSKqhv7LB3HRgqyevwmCScfJUwFVJi_6sI5eGkJ2jKBfxgjFZRUXfSe0sxCms$
>
>
> > On Dec 2, 2020, at 1:39 PM, Susan Hinrichs 
> wrote:
> >
> > The analysis of this crash is in
> https://urldefense.com/v3/__https://github.com/apache/trafficserver/issues/7338__;!!BhdT!z8VSKqhv7LB3HRgqyevwmCScfJUwFVJi_6sI5eGkJ2jKBfxgjFZRUXfS2K83kmk$
> .
> >
> > On Wed, Dec 2, 2020 at 12:44 PM Leif Hedstrom  wrote:
> >
> >
> > > On Dec 2, 2020, at 10:01 AM, Susan Hinrichs 
> wrote:
> > >
> > > -1
> > >
> > > Concern about the second PR that Masaori identified.  The original PR
> caused asserts with a debug build..  I am testing another fix to this in
> production.  Looking good so far.  I will update the PR shortly.
> > >
> > > Without this patch, the 9.0.x build crashes on a production machine
> within an hour.
> >
> >
> > Is this a new crasher that was added recently to 9.0.x? Concerned that
> we didn’t identify this earlier. I agree that we should respin 9.0.x with
> both of these fixes. I’m running with the merged 9.0.x PRs,  which includes
> the SplitDNS fixes, but seems we need a PR for # 7338 ?
> >
> > — Leif
> >
> >
> > >
> > > 2). 9.0.x Inactivity Cop Crash #7338 We have a PR to fix this, but
> > > Susan is still working on it.
> > >
> > > Adjust flags to ensure tunnel producer is cleaned up #7336
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apac
> > > he_trafficserver_pull_7336=DwIFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT
> > > 9yOhqES_g_wVY=GAqM_xZpxNbVqsR-aGvQBjOG3d33Y2-i4ynL-JkEouY=sK6Ut1
> > > WmZ_DeZB66ARXnJ4ISiQiWkZABXWtLyf95i-o=Ibxs8F8y1fPafzISx1-MCPvuDtZE
> > > TQC_GHLGcZF3Jdo=
> > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apa
> > > che_trafficserver_pull_7336=DwMFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmi
> > > T9yOhqES_g_wVY=GAqM_xZpxNbVqsR-aGvQBjOG3d33Y2-i4ynL-JkEouY=AEqUL
> > > LM-j6ogI0fUl61qB2bgk_NfqO8WTe-wnvWsTEs=EuuYIeJ-79nYpL2SBBXDVFuHhS5
> > > m6nW9fwvS6R6CkUs=>
> > >
> > > On Tue, Dec 1, 2020 at 6:49 PM Masaori Koshiba  <mailto:masa...@apache.org>> wrote:
> > > +0, some issues are not backported or fixed yet. These will go to the
> next patch release?
> > >
> > > 1). 9.0.x SplitDNS is not working #7319 This is fixed. Please
> > > cherry-pick the below commits.
> > >
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apac
> > > he_trafficserver_commit_4e2ac3b2be8b535ab89d0f5762b3201647e5efba=D
> > > wIFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=GAqM_xZpxNbVqs
> > > R-aGvQBjOG3d33Y2-i4ynL-JkEouY=sK6Ut1WmZ_DeZB66ARXnJ4ISiQiWkZABXWtL
> > > yf95i-o=8YJIHsM5lhSMSp9DcPAgawN7KvlYXM1mNPbZ5Nrpdfg=
> > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apa
> > > che_trafficserver_commit_4e2ac3b2be8b535ab89d0f5762b3201647e5efba=
> > > DwMFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=GAqM_xZpxNbVq
> > > sR-aGvQBjOG3d33Y2-i4ynL-JkEouY=AEqULLM-j6ogI0fUl61qB2bgk_NfqO8WTe-
> > >

Re: [E] pssc/proxy response status code: 000

[Susan Hinrichs]

It means that ATS did not get an origin response before the transaction
ended.  If the transaction lasted 30 seconds, it seems likely that your
client or origin timed out.  Either due to the inactivity_timeout's set in
ATS, or due to timeout logic in the client or origin.

On Tue, Dec 8, 2020 at 8:55 AM Andreas Wederbrand 
wrote:

> Hi!
>
> I'm running ATS (7.x) as a reverse proxy and I'm seeing something weird.
> For some clients I get pssc = 000 on the exit, for most it's 200.
>
> This always happens after 30 seconds but ats i configured to allow longer
> requests than that, and with curl or insomnia it happily runs for 30+
> seconds.
>
> I've tried to set at timeout both in curl and insomnia to check if 000
> means that the client went away but ats happily logs the result with
> duration or 30+ seconds, long after the client terminitade.
>
> So, I guess the question is: what does pssc = 000 mean?
>
> Thanks.
>

Re: [E] https issue

[Susan Hinrichs]

The --resolve option is very helpful for using curl to direct requests to
the proxy to terminate.

curl -k -v --resolve 'httbin.org:4443:127.0.0.1'
https://httpbin.org:4443/get?answer=4a

Adding the -k assuming you are using a self-signed cert in ATS for
testing.  Also assuming your ATS is configured to listen for TLS on port
4443 in this example.

On Thu, Dec 3, 2020 at 1:29 PM Alan Carroll <
solidwallofc...@verizonmedia.com> wrote:

> You will need to set up the certificates for ATS in that case. Although it
> is possible to do this in "records.config", that is (IMHO) deprecated
> because it has been superceded by "ssl_multicert.config". I would start
> with that directly, it will be easier.
>
> https://docs.trafficserver.apache.org/en/latest/admin-guide/files/ssl_multicert.config.en.html
> 
> If there is only a single certificate, you will want to use "dest_ip=*" as
> the configuration which will use that certificate for all outbound
> connections.
> You'll need to use different options to curl to test this, as using
> "--proxy" with an "https" destination will always bypass TLS on the proxy.
>
>
> On Thu, Dec 3, 2020 at 1:03 PM Lei Sun  wrote:
>
>> Hi Alan,
>>
>> Thanks for responding! Yes, I learned about the CONNECT method.
>>
>> I can confirm that for the "https" method, I don't want the client to do
>> TLS directly with the server. Instead, I'd like the trafficserver to take
>> that request, decrypt it, then pretend to be a client, and do TLS on
>> behalf of the client with the upstream.
>>
>> Thanks,
>> Lei
>>
>>
>>
>> On Thu, Dec 3, 2020 at 12:13 PM Alan Carroll <
>> solidwallofc...@verizonmedia.com> wrote:
>>
>>> The first thing to note is "curl --proxy" behaves very differently if
>>> the target URL is "http" vs. "https". In the former case, curl will do a
>>> TCP network connection to the proxy and then sends a GET request. In the
>>> latter case, as you can see from the output, it does a TCP network
>>> connection to the proxy and then sends a CONNECT (not a GET) to the proxy.
>>> After this, curl will do TLS negotiation with the upstream, NOT with ATS.
>>> It is unclear from your description if this is what you want.
>>>
>>> So, first question - should ATS do TLS negotiation with the user agent
>>> and decrypt the request? Or should it just do a blind tunnel pass the raw
>>> bytes to the upstream so the upstream does the TLS with the user agent?
>>>
>>> On Wed, Dec 2, 2020 at 5:41 PM Lei Sun  wrote:
>>>
 Hi Kit,

 I'm trying to set up the trafficserver as an intermediary forward proxy.

 For example,
 1) http client send request to trafficserver.
 2) trafficserver then pass this request to the downstream proxy
 3) downstream proxy then route this request to the origin site
 4) origin site send data back to the downstream proxy
 5) downstream proxy send data back to trafficserver
 6) trafficserver send data back to the http client.

 I was able to make the entire request chain work if the origin site
 serves content directly through HTTP.

> curl --proxy *http*://127.0.0.1:8080
> 
> *http*://httpbin.org/get?answer=4a
> 
> -v


 However, I ran into issues when I was trying to request for content
 served from HTTPS.

 $ curl --proxy *http*://127.0.0.1:8080
> 
> *https*://httpbin.org/get?answer=4a
> 
> -v
> *   Trying 127.0.0.1...
> * TCP_NODELAY set
> * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> * Establish HTTP proxy tunnel to httpbin.org:443
> 

Re: [E] [VOTE] Release Apache Traffic Server 9.0.0 (RC0)

[Susan Hinrichs]

The analysis of this crash is in
https://github.com/apache/trafficserver/issues/7338.

On Wed, Dec 2, 2020 at 12:44 PM Leif Hedstrom  wrote:

>
>
> > On Dec 2, 2020, at 10:01 AM, Susan Hinrichs 
> wrote:
> >
> > -1
> >
> > Concern about the second PR that Masaori identified.  The original PR
> caused asserts with a debug build..  I am testing another fix to this in
> production.  Looking good so far.  I will update the PR shortly.
> >
> > Without this patch, the 9.0.x build crashes on a production machine
> within an hour.
>
>
> Is this a new crasher that was added recently to 9.0.x? Concerned that we
> didn’t identify this earlier. I agree that we should respin 9.0.x with both
> of these fixes. I’m running with the merged 9.0.x PRs,  which includes the
> SplitDNS fixes, but seems we need a PR for # 7338 ?
>
> — Leif
>
>
> >
> > 2). 9.0.x Inactivity Cop Crash #7338
> > We have a PR to fix this, but Susan is still working on it.
> >
> > Adjust flags to ensure tunnel producer is cleaned up #7336
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_trafficserver_pull_7336=DwIFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=GAqM_xZpxNbVqsR-aGvQBjOG3d33Y2-i4ynL-JkEouY=sK6Ut1WmZ_DeZB66ARXnJ4ISiQiWkZABXWtLyf95i-o=Ibxs8F8y1fPafzISx1-MCPvuDtZETQC_GHLGcZF3Jdo=
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_trafficserver_pull_7336=DwMFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=GAqM_xZpxNbVqsR-aGvQBjOG3d33Y2-i4ynL-JkEouY=AEqULLM-j6ogI0fUl61qB2bgk_NfqO8WTe-wnvWsTEs=EuuYIeJ-79nYpL2SBBXDVFuHhS5m6nW9fwvS6R6CkUs=
> >
> >
> > On Tue, Dec 1, 2020 at 6:49 PM Masaori Koshiba  <mailto:masa...@apache.org>> wrote:
> > +0, some issues are not backported or fixed yet. These will go to the
> next patch release?
> >
> > 1). 9.0.x SplitDNS is not working #7319
> > This is fixed. Please cherry-pick the below commits.
> >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_trafficserver_commit_4e2ac3b2be8b535ab89d0f5762b3201647e5efba=DwIFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=GAqM_xZpxNbVqsR-aGvQBjOG3d33Y2-i4ynL-JkEouY=sK6Ut1WmZ_DeZB66ARXnJ4ISiQiWkZABXWtLyf95i-o=8YJIHsM5lhSMSp9DcPAgawN7KvlYXM1mNPbZ5Nrpdfg=
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_trafficserver_commit_4e2ac3b2be8b535ab89d0f5762b3201647e5efba=DwMFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=GAqM_xZpxNbVqsR-aGvQBjOG3d33Y2-i4ynL-JkEouY=AEqULLM-j6ogI0fUl61qB2bgk_NfqO8WTe-wnvWsTEs=fe-HYNLLR73gn1KzwMH7x7htggG5pOaFCgVqCmU4s24=
> >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_trafficserver_commit_3f11f151db24ec92ea0af61197401e5b10144e27=DwIFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=GAqM_xZpxNbVqsR-aGvQBjOG3d33Y2-i4ynL-JkEouY=sK6Ut1WmZ_DeZB66ARXnJ4ISiQiWkZABXWtLyf95i-o=vABzCX4_plojMcLxnUrB6fYugRj-VPlgmIwAmAIXp5Y=
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_trafficserver_commit_3f11f151db24ec92ea0af61197401e5b10144e27=DwMFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=GAqM_xZpxNbVqsR-aGvQBjOG3d33Y2-i4ynL-JkEouY=AEqULLM-j6ogI0fUl61qB2bgk_NfqO8WTe-wnvWsTEs=Qu91oBGJnIK4SAww9ZpLM-OxUyNINpEHTFcf_GAudCQ=
> >
> >
> > 2). 9.0.x Inactivity Cop Crash #7338
> > We have a PR to fix this, but Susan is still working on it.
> >
> > Adjust flags to ensure tunnel producer is cleaned up #7336
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_trafficserver_pull_7336=DwIFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=GAqM_xZpxNbVqsR-aGvQBjOG3d33Y2-i4ynL-JkEouY=sK6Ut1WmZ_DeZB66ARXnJ4ISiQiWkZABXWtLyf95i-o=Ibxs8F8y1fPafzISx1-MCPvuDtZETQC_GHLGcZF3Jdo=
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_trafficserver_pull_7336=DwMFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=GAqM_xZpxNbVqsR-aGvQBjOG3d33Y2-i4ynL-JkEouY=AEqULLM-j6ogI0fUl61qB2bgk_NfqO8WTe-wnvWsTEs=EuuYIeJ-79nYpL2SBBXDVFuHhS5m6nW9fwvS6R6CkUs=
> >
> >
> > — Masaori
> >
> > On Wed, Dec 2, 2020 at 8:09 AM Bryan Call  bc...@apache.org>> wrote:
> > This is the next major release of ATS!
> >
> > I've prepared a release for 9.0.0.  The release notes for 9.0.0 are
> available at:
> >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_trafficserver_pulls-3Fq-3Dis-253Aclosed-2Bis-253Apr-2Bmilestone-253A9.0.0=DwIFaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=GAqM_xZpxNbVqsR-aGvQBjOG3d33Y2-i4ynL-JkEouY=sK6Ut1WmZ_DeZB66ARXnJ4ISiQiWkZABXWtLyf95i-o=G_H3NBoqbf1C_ZbqPGbb1UmpsVb2nDa1LnSXbuOBFGw=
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_trafficserver_pulls-3Fq-3Dis-253Acl

Re: [E] Re: [VOTE] Release Apache Traffic Server 9.0.0 (RC0)

[Susan Hinrichs]

-1

Concern about the second PR that Masaori identified.  The original PR
caused asserts with a debug build..  I am testing another fix to this in
production.  Looking good so far.  I will update the PR shortly.

Without this patch, the 9.0.x build crashes on a production machine within
an hour.

2). 9.0.x Inactivity Cop Crash #7338
We have a PR to fix this, but Susan is still working on it.

Adjust flags to ensure tunnel producer is cleaned up #7336
https://github.com/apache/trafficserver/pull/7336


On Tue, Dec 1, 2020 at 6:49 PM Masaori Koshiba  wrote:

> +0, some issues are not backported or fixed yet. These will go to the next
> patch release?
>
> 1). 9.0.x SplitDNS is not working #7319
> This is fixed. Please cherry-pick the below commits.
>
>
> https://github.com/apache/trafficserver/commit/4e2ac3b2be8b535ab89d0f5762b3201647e5efba
> 
>
> https://github.com/apache/trafficserver/commit/3f11f151db24ec92ea0af61197401e5b10144e27
> 
>
> 2). 9.0.x Inactivity Cop Crash #7338
> We have a PR to fix this, but Susan is still working on it.
>
> Adjust flags to ensure tunnel producer is cleaned up #7336
> https://github.com/apache/trafficserver/pull/7336
> 
>
> — Masaori
>
> On Wed, Dec 2, 2020 at 8:09 AM Bryan Call  wrote:
>
>> This is the next major release of ATS!
>>
>> I've prepared a release for 9.0.0.  The release notes for 9.0.0 are
>> available at:
>>
>>
>> https://github.com/apache/trafficserver/pulls?q=is%3Aclosed+is%3Apr+milestone%3A9.0.0
>> 
>> <
>> https://github.com/apache/trafficserver/pulls?q=is:closed+is:pr+milestone:9.0.0
>> 
>> >
>>
>>
>> or for a brief ChangeLog:
>>
>>
>> https://github.com/apache/trafficserver/blob/9.0.x/CHANGELOG-9.0.0
>> 
>> > 
>> >
>>
>>
>> For some details as to what’s new in 7.1.x see:
>>
>>
>> https://docs.trafficserver.apache.org/en/9.0.x/release-notes/whats-new.en.html
>> 
>> <
>> https://docs.trafficserver.apache.org/en/9.0.x/release-notes/whats-new.en.html
>> 

Re: [E] ATS 7.1 as reverse proxy timeouts on POST after 30 seconds instead of 1800 seconds

[Susan Hinrichs]

There are two kinds of timeouts involved.  One is the various
*connect_attempts_timeout.  This timeout only applies while the connection
to the origin is being established (e.g. TLS handshake or TCP three-way for
non-TLS).  Then the regular
proxy.config.http.transaction_no_activity_timeout_out applies while waiting
for the first byte and all other bytes exchanged with the origin.

But you are running 71.  The connect_timeouts may have been applied until
the first byte was received.  I think this was fixed to be the proper
connect timeout instead of TTFB timeout in the 8.x timeframe.  So in that
case any POST/PUT method requests would by default wait 1800 seconds for
the first byte to return.  All other methods would wait the time specified
in proxy.config.http.connect_attempts_timeout which appears to default to
30 seconds.

Susan

On Fri, Nov 20, 2020 at 8:16 AM Andreas Wederbrand 
wrote:

> Hi!
>
> I'm running ATS 7.1 as a reverse proxy and one of our origins takes 30+
> seconds occasionally. I thought that
> *proxy.config.http.post_connect_attempts_timeout* would control that. It
> is set to it's default of 1800 seconds (30 minutes!?) but we still see a
> 504 after 30 seconds.
>
> Am I missing something? Am I looking at the wrong configuration?
>
> Thanks.
>

Re: [E] Stress-resistance settings || or any advise please?

[Susan Hinrichs]

One last question.  What is the bandwidth of your WAN connection?  Is it
possible that your client requests are overwhelming the network?

On Mon, Oct 19, 2020 at 12:13 PM pentester  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>   Dear Susan, once again thank you very much for your valuable
> feedback. I really highly appreciate it.
>
> Well, to be honest this is a test environment just for playing with ATS
> (especialy to create env to mitigate layer 7 DDoS attacks etc cases.) I
> did nothing to server setup (no pre-configured ports reuse / no
> increased security limits etc. Just default Centos 8 installation)
>
> For the second part:
> "Do your client requests (and sql requests) just timeout after
> bit?"
>
> Well, i'm not sure about timeout but definitely mysqld goes down
> (according to journal files i can see that records too (mysql server
> has gone aways etc)
>
> Currently, for prod i did cookie based checking via ATS (human or bot)
> but i'm sure it will not help in such cases when someone smashes the
> server via httpress over Cloudflare. The only working mitigation /
> solution i think should be Cloudflare + "I'm under attack mode" +
> additionally ATS's cookie based checking something like this:
>
>
> cond %{READ_REQUEST_HDR_HOOK}
> cond %{COOKIE:botorhuman} = ""
> set-status 403
>
> or rate limiting (without Cloudflare)
>
>
> I'll try to play with port: with "local port range and other port reuse
> settings " and increasing / decreasing default security limits too.
>
> Plus for future i'm planning to use ingres shaping / policing? to
> mitigate such cases. Better to try than nothing)
>
> Once again thank you very much!
>
>
> Cheers,
>
>
>
>
> On Mon, 2020-10-19 at 11:43 -0500, Susan Hinrichs wrote:
> > So definitely not a memory problem.
> >
> > Do your client requests (and sql requests) just timeout after a
> > bit?  If
> > I'm reading your netstat output correctly, traffic_server just has
> > 2600
> > sockets open for port 80, which does not seem like too many.
> >
> > It is quite easy in a single client stress test to run out of
> > ephemeral
> > ports from the single client to the server. But that should affect
> > connections to other processes such as SQL.  I assume that you've
> > already
> > adjusted the local port range and other port reuse settings on your
> > tests
> > boxes to set up more ephemeral ports.
> >
> > On Mon, Oct 19, 2020 at 10:51 AM pentester 
> > wrote:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > >
> > >   Hello Susan!
> > >
> > > Thank you for your feedback. Well, i think my conclusion is wrong
> > > about
> > > 500 concurrent connections against ATS.
> > > Because: httpress -n 1 -c 500 -t 4 '
> > > http://mytestsite.domain/'
> > >
> > > 4 threads x 500 concurrent connections against ATS does = 2000
> > > concurrent connnects.
> > >
> > > Anyways, it gets down for me: the symtoms is: under that high load
> > > test: ATS starves all available sockets on server.
> > > So as result: ATS = is unable to accept new connections, MYSQL,
> > > HTTPD
> > > (origin) also gets down (mysql server has gone aways etc).
> > > Sockets starvation + CPU starvation.
> > >
> > > In fact when i do stress test from other box (over WAN) any request
> > > reaching ATS should get (and gets i can confirm) 403 (ATS's 403)
> > > because i wrote simple rule to get always 403 against requests. So
> > > i
> > > can confirm my concurrent requests never reaches origin (HTTPD).
> > >
> > >
> > > Here is what i see under the stress-test:
> > >
> > > # traffic_top
> > >
> > > Disk Used1.2MRam
> > > Hit 40.8%   GET  1.2%200 53.5%
> > > Disk Total
> > > 837.8MFresh0.3%   HEAD 0.2%206  0.0
> > > %
> > > Ram
> > > Used99.8KRevalidate   0.0%   POST 0.2%301
> > > 0.0%
> > > Ram
> > > Total4.3GCold98.8%   2xx 53.5%302
> > > 1.3%
> > > Lookups  7.2KChanged  0.5%   3xx 45.4%304
> > >44.0%
> > > Writes   0.0 Not
> > > Cache0.0%   4xx  1.1%404  0.8%
> > > Updates 37.0 No
> > > Cache 0.0%   5xx  0.0%502  0.0%
> > >

Re: [E] Stress-resistance settings || or any advise please?

[Susan Hinrichs]

on
> #
>
> https://docs.trafficserver.apache.org/en/latest/admin-guide/files/logging.yaml.en.html
> ###
> ###
> CONFIG proxy.config.log.logging_enabled INT 3
> CONFIG proxy.config.log.max_space_mb_for_logs INT 25000
> CONFIG proxy.config.log.max_space_mb_headroom INT 1000
> CONFIG proxy.config.log.rolling_enabled INT 1
> CONFIG proxy.config.log.rolling_interval_sec INT 86400
> CONFIG proxy.config.log.rolling_size_mb INT 10
> CONFIG proxy.config.log.auto_delete_rolled_files INT 1
> CONFIG proxy.config.log.periodic_tasks_interval INT 5
>
> ###
> ###
> # These settings control remapping, and if the proxy allows (open)
> forward proxy or not. Docs:
> #
> https://docs.trafficserver.apache.org/records.config#url-remap-rules
> #
>
> https://docs.trafficserver.apache.org/en/latest/admin-guide/files/remap.config.en.html
> ###
> ###
> CONFIG proxy.config.url_remap.remap_required INT 1
> #
>
> https://docs.trafficserver.apache.org/records.config#proxy-config-url-remap-pristine-host-hdr
> CONFIG proxy.config.url_remap.pristine_host_hdr INT 0
> #
> https://docs.trafficserver.apache.org/records.config#reverse-proxy
> CONFIG proxy.config.reverse_proxy.enabled INT 1
>
> ###
> ###
> # SSL Termination. Docs:
> #
>
> https://docs.trafficserver.apache.org/records.config#client-related-configuration
> #
>
> https://docs.trafficserver.apache.org/en/latest/admin-guide/files/ssl_multicert.config.en.html
> ###
> ###
> CONFIG proxy.config.ssl.client.verify.server INT 0
> CONFIG proxy.config.ssl.client.CA.cert.filename STRING NULL
> CONFIG proxy.config.ssl.server.cipher_suite STRING ECDHE-ECDSA-AES256-
> GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-
> SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-DSS-
> AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-
> SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-
> AES256-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-
> AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-
> AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-
> AES128-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES128-
> SHA:DHE-DSS-AES128-
> SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-
> SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
>
> ###
> ###
> # Debugging. Docs:
> #
>
> https://docs.trafficserver.apache.org/records.config#diagnostic-logging-configuration
> ###
> ###
> CONFIG proxy.config.diags.debug.enabled INT 0
> CONFIG proxy.config.diags.debug.tags STRING http|dns
> # ToDo: Undocumented
> CONFIG proxy.config.dump_mem_info_frequency INT 0
> CONFIG proxy.config.http.slow.log.threshold INT 0
>
> CONFIG proxy.config.hostdb.host_file.path STRING /etc/hosts
>
>
> #CONFIG proxy.config.thread.default.stacksize INT 3145728
>
>
> CONFIG proxy.config.cache.ram_cache.size INT 4G
> CONFIG proxy.config.net.inactivity_check_frequency INT 80
>
>
>
> - 
>
>
>
> Cheers,
>
>
>
>
> On Mon, 2020-10-19 at 08:29 -0500, Susan Hinrichs wrote:
> > Sounds like ATS should be able to keep up with that work
> > load.  However,
> > I've not worked with httpress specifically, so I'm not certain what
> > kind of
> > RPS those arguments would correspond to..
> >
> > How did your ATS box fail?  Did it crash?  Did it just get so slow
> > that the
> > requests started timing out?  Is your request mapping through to an
> > origin?  Or hitting cache?
> >
> > I would start looking at memory usage.  If ATS starts swapping,
> > things go
> > downhill fast.  If you are caching, how much ram cache do you have
> > configured?  If you aren't caching, does you configuration still have
> > ram
> > cache enabled?
> >
> > Susan
> >
> > On Sun, Oct 18, 2020 at 3:11 PM pentester 
> > wrote:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > >
> > >Hello Folks!
> > >
> > > I need your valuable advise regarding how to fine-tune ATS for
> > > highly
> > > loaded server.
> > >
> > > The situat

Re: [E] Stress-resistance settings || or any advise please?

[Susan Hinrichs]

Sounds like ATS should be able to keep up with that work load.  However,
I've not worked with httpress specifically, so I'm not certain what kind of
RPS those arguments would correspond to..

How did your ATS box fail?  Did it crash?  Did it just get so slow that the
requests started timing out?  Is your request mapping through to an
origin?  Or hitting cache?

I would start looking at memory usage.  If ATS starts swapping, things go
downhill fast.  If you are caching, how much ram cache do you have
configured?  If you aren't caching, does you configuration still have ram
cache enabled?

Susan

On Sun, Oct 18, 2020 at 3:11 PM pentester  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>Hello Folks!
>
> I need your valuable advise regarding how to fine-tune ATS for highly
> loaded server.
>
> The situation:
> Test server: (VPS) CPU(s) 4 (Intel(R) Xeon(R) CPU E5-2630 v4 @
> 2.20GHz), Total RAM: 8 GB, HDD (SSD)
> OS: Centos 8
> ATSv: 8.1.0
>
> Problem: According to ATS documentation and it's default config files
> it can handle 30k concurrent requests. That's great!
>
> //records.config
> CONFIG proxy.config.net.connections_throttle INT 3
> CONFIG proxy.config.net.max_connections_in INT 3
> CONFIG proxy.config.net.max_connections_active_in INT 3
>
>
>
> **During the the stress-test: 400-500 concurrent connections against
> simple 403 page completely downs ATS. (over WAN)
>
> httpress -n 1 -c 500 -t 4 'http://mytestsite.domain/'
>
>
> (?) Question:
> Should i play with settings / fine-tune them (if yes, please let me
> know them) or better to upgrade HW / or any other advise on this
> please.
>
>
> Played a bit with the following settings (increased/decreased them). No
> avail.
>
> proxy.config.net.connections_throttle
> proxy.config.net.max_connections_in
> proxy.config.net.max_connections_active_in
>
>
> proxy.config.http.keep_alive_no_activity_timeout_in
> proxy.config.http.keep_alive_no_activity_timeout_out
> proxy.config.http.transaction_no_activity_timeout_in
> proxy.config.http.transaction_no_activity_timeout_out
>
>
>
> Thanks in advance!
>
>
>
>
>
> - -BEGIN PGP PUBLIC KEY BLOCK-
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> mQINBF68kXkBEAD9fDwkcQqbbgbAa7/Oy07r2Lt2SoYbQFAlK8ECa+25QlNdvfH5
> c/EBrvb5hyE5D33AZdv9Dee40OTmJGQQc1M6jDb8iOlZiNaDc3ZcfZzGhhKsEFNr
> hWPnaC+58Z0dTjpG03dRRWFs1Xrn1r2HTqhq5rG5UddnPT3pwFjQBuSxJTGn3i9P
> tZKl7WPgmfXgGXKDit+tAEjqPRFgiMkJYqsDJZFd+Xoon8Bi/6LK1asxykb/2qrY
> maEaWkJ7x5nzio/5pne0/OVZtExZCK3439ibEI0ppzNHcCEhua1Kk3SzQXFcvt6s
> 9QssaC/N/njm07eEJ7GyvV6w9NtJRgQZ0Bf8uYFEkDgdtHnkVnCr/YsS3f1Yl63c
> gOPMPxYaZrUjYWrJEnm2V5XxdoVYs4s8gxY6jEQ5oWQmMpkPhOekWMkOw+3p+hFn
> 2nyZhdb8KkvWa34Lif3fNfNoKhk0PWD+rwG9BwqTKxEAUVmxHvy74F1hvzYk+5IL
> zCDzwGTpCQ/xgIdnjfHdel0tOOIgCnXCsyh/sFuB4XsoVeFdnrws2nVZQVXLWFJF
> va8WpzVLWr2twHO6Z3pB10JbQcFEPBnYlCO8pcZvydLwcrROG9G2PrUBHWjvQD0o
> 2kpDC89byGpMVM1cx8AWq7sDtjYeW6vrcFJaHarymG1DzAFUjYO9UhMgNwARAQAB
> tB9wZW50ZXN0ZXIgPHBlbnRlc3RAY2VydC5nb3YuYXo+iQI/BBMBAgApBQJevJF5
> AhsDBQkB4TOABwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQytVB6cybO77G
> Qg//StzzAgIHZHuDMh94Kh/qOSAxynumTnhZ6VZU0/59CzQUu285cLpZUmPwJdaz
> GmS795NwZVnbla3bKm1HR7d2LwOB24rSgoCPgbTEqMxDzm2KbdOnnSi98vdRGdWp
> p3nS7T6oZ2+6CPY8Pg+hvD8LfhwdcUmVNhDENrZ0agSEBmdj+At+7jOBbQUvSKPk
> Revw/kdQeo+SZKOE2gs/MDJsaSFv4lhyTy6jKbPFHbk5C+ZJ32BPDL3IZ02pdUVZ
> WKBnX5d3z9EHliKpMyZHQu2998t9wz447ab9W7AIxhuD+vqjrQYRLFk2oKb3/eDW
> RPDRIfCk2py9+e9j38cnPhtsmXO5eYoXa4mbBwMPieCqRfN3Msna7USbPbe4mfgb
> AIdrJCYj2TrYs6ErdRXpb4I60iXZlTWXYdQlVYLLdn2Sb6lqfgREhryLZADxIcoN
> YwYSJE3NsULKlhPub4wOMCIIaQk7GLz02ZcFGORTtnFKHcg91GqcNCj7SGu+2C3n
> hpPNJVDnbgU4XToMmKgALFpG82JXEuQYUOH8/SB+qlrBMCwoSuLSO2Tu5l0hHCWw
> bp8al8yIMHCfqAvrCntGE+rpJKHvO7BhzL+tvvA3HJn4loKhMq9J8v+gI+YEjUsU
> WpEOmusARUiBVi4MlUxoNQH8yS7zMNXkFoaQOf+yWH3BCSi5Ag0EXryReQEQANsd
> iZZW8vt4STelg0D/PW4sRYUgm0gQgp/V6PlOiwlJ+x7DRCdEtlzLnr/wyB0TbwHO
> 7hxAhAlAHjgTAbDYAuz2Scm9OiiNiZpJqL/ka9gsVVczXgZzgWg9cuFtHc8CMPjs
> 0D7yqc6ANQeVJLCqJ/+4jyQzNc5VZPm+tJ6hnTLcEaok+9dPnB8/9cVo88tVhWN+
> /9jvGAxB/rcfY+eQEBwxmOk9w74Vs0Fj1pIcsZYrWounYG4Dh9/O+xw3E0mr1Sj2
> YJmpTWRrUqLqxeGm5lptn9HBTA6qecJrX9urh7djXUbcRZcptBpaHfYvO1lcvRhZ
> 6ndpNAnknp/6FaCCqWKwKkAr3TtB7uJbxz+xJAi+fU2ZOkyNeBlavzmZinRRmujn
> Rdkqgtks0qUMQVdbNju/A36O9uVZyEm+lkMFNNq+Q0dehRLsUjYJJywCjB7Pwa6d
> FmrRGhTxd9J1qxkzCue941TNYJkPfVAuhyuAAO85TXi3fF20QdxC4IgIzl39xScY
> k/gTzIbDUFlKn+BIC5O2QSLpof8r0qhkZIXA3D/6HBMpT9IemI2BeOf6VpwN66nn
> sJqk/3t8naS5nxyZ8lQe85JOyxane5KT7mRK+x9vyBixlnWh3UhRbMP8/TyrY0/n
> qySu0VOrQn2FlssL13EWvsi45rY13h0i2UcEI641ABEBAAGJAiUEGAECAA8FAl68
> kXkCGwwFCQHhM4AACgkQytVB6cybO76hSRAA2v5Wf1C9yJBCr/USYRcgsmbJNWlc
> gm4agVBorFxBlr3+D3numYNNfm20PenYku/UBgMK5bCr67S2+0xo97RnDcRudbAx
> sV49/1xVPjjwj5HCY0EFS34oKKoGMp57ll4ewbAdBwgz8j6ld72Mg05ZReLKbtWr
> 9h12VaO1JrGC+XzCTWJc1pDWB5Q3Sv2UENpjr203jIlE44O7qepfaP+3bnWPMmG7
> oQlmuggx/k3nbLPUiCcYLg5yiYBmTQHTUnB4v5L2nT3IEG2DbuEqWbwewIsGaSx9
> eGG2gkRtJNpRSS6+sWMFKOW7RR2YgDQoNm5XOwgZhoMYwXs5fD0ul5kFVfVPYYOl
> 

Re: [E] Query

[Susan Hinrichs]

The master branch includes an iCAP plugin.  We have used that plugin to
integrate with a Symantec filtering product and some preliminary testing
with Clam AV.  It is not merged into the 9.0.x branch so the earliest it
would show up in an official release is 9.1.x or 10.x..

Susan

On Wed, Oct 14, 2020 at 2:10 AM Trilok Nathreddy  wrote:

> From the documentation seems ATS supports ICAP and can integrate with
> Symantec engine / C-ICAP with Clam AV scanning. So just checking if ATS can
> integrate with  API based scanning solutions ?
>
> Regards
> Trilok
>

Re: [PROPOSAL] TS API for Status,Note,Warning,Alert

[Susan Hinrichs]

+1

On Tue, Sep 8, 2020 at 1:34 PM Alan Carroll <
solidwallofc...@verizonmedia.com> wrote:

> +1.
>
> On Tue, Sep 8, 2020 at 12:04 PM Aaron Canary 
> wrote:
>
>> I'd like to propose adding API calls for the remaining methods in diag.h:
>> TSStatus(const char *fmt, ...) // prints to diags log (informational)
>> TSNote(const char *fmt, ...) // prints to diags log (implies significance)
>> TSWarning(const char *fmt, ...) // prints to diags log (implies concern)
>> TSAlert(const char *fmt, ...) // exit and restart, prints to diags
>> log (implies needs attention)
>>
>> The following are already exposed through the API:
>> TSDebug(const char* tag, const char *fmt, ...) // print to stderr
>> TSError(const char *fmt, ...) // prints to diags log (implies operation
>> failure, causes test fail in CI)
>> TSFatal(const char *fmt, ...) // exit and restart, prints to diags log
>> TSEmergeny(const char *fmt, ...). // exit and don't restart, prints to
>> diags log
>>
>> I'd like to add these to the TS API, and update the documentation to
>> directly describe the uses of each. I'm not interested in changing any
>> functionality of diags.h/.cc at the moment, just exposing for plugins to
>> use.
>>
>> Corrections? Major objections or concerns?
>> I'll reply here with the PR when it's ready. That might be a better forum
>> to discuss the details.
>>
>

Re: Extended Master Secret extension and session ticket reuse

[Susan Hinrichs]

Yes there is a --with-openssl option.  I have my openssl rooted at /opt, so
I use the following option when calling configure.

--with-openssl=/opt/openssl/1.1.1

On Thu, Jul 16, 2020 at 9:20 AM supraja sridhar 
wrote:

> Is there a way to specify the path of openssl 1.1.1 library in the system
> through configure script of ATS?
>
> On Wed, Jul 15, 2020 at 8:39 PM Susan Hinrichs 
> wrote:
>
>> I think the version of openssl is it.  A quick grep through the code it
>> appears that openssl 1.1.1 supports extended master secret but openssl
>> 1.0.2 does not.  Interestingly you cannot turn off extended master secret
>> in 1.1.1.  The SSL_OP_NO_EXTENDED_MASTER_SECRET option doesn't appear
>> until openssl 3.
>>
>>
>> On Wed, Jul 15, 2020 at 4:38 AM supraja sridhar <
>> suprajasridha...@gmail.com> wrote:
>>
>>> Hello,
>>> Yes, I am using ATS 7.1.1 with openssl 1.0.2 version. The client
>>> supports the extended master secret extension. Could the openssl version be
>>> an issue?
>>>
>>> On Tue, Jul 14, 2020 at 5:45 PM Susan Hinrichs <
>>> shinr...@verizonmedia.com> wrote:
>>>
>>>> Yes, I believe it should.  ATS doesn't set 
>>>> SSL_OP_NO_EXTENDED_MASTER_SECRET,
>>>> and the default is for that feature to be enabled.
>>>>
>>>> Are you having problems with session reuse?  Perhaps the client does
>>>> not support the Extended Master secret?
>>>>
>>>> Susan
>>>>
>>>> On Tue, Jul 14, 2020 at 1:26 AM supraja sridhar <
>>>> suprajasridha...@gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Does ATS 7.x support session ticket reuse in the presence of Extended
>>>>> Master secret extension in the handshake ?
>>>>>
>>>>> Thanks
>>>>> Supraja
>>>>>
>>>>
>>>
>>> --
>>> Regards,
>>> S.SUPRAJA
>>> MIT
>>>
>>
>
> --
> Regards,
> S.SUPRAJA
> MIT
>

Re: Extended Master Secret extension and session ticket reuse

[Susan Hinrichs]

I think the version of openssl is it.  A quick grep through the code it
appears that openssl 1.1.1 supports extended master secret but openssl
1.0.2 does not.  Interestingly you cannot turn off extended master secret
in 1.1.1.  The SSL_OP_NO_EXTENDED_MASTER_SECRET option doesn't appear until
openssl 3.


On Wed, Jul 15, 2020 at 4:38 AM supraja sridhar 
wrote:

> Hello,
> Yes, I am using ATS 7.1.1 with openssl 1.0.2 version. The client supports
> the extended master secret extension. Could the openssl version be an issue?
>
> On Tue, Jul 14, 2020 at 5:45 PM Susan Hinrichs 
> wrote:
>
>> Yes, I believe it should.  ATS doesn't set SSL_OP_NO_EXTENDED_MASTER_SECRET,
>> and the default is for that feature to be enabled.
>>
>> Are you having problems with session reuse?  Perhaps the client does not
>> support the Extended Master secret?
>>
>> Susan
>>
>> On Tue, Jul 14, 2020 at 1:26 AM supraja sridhar <
>> suprajasridha...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> Does ATS 7.x support session ticket reuse in the presence of Extended
>>> Master secret extension in the handshake ?
>>>
>>> Thanks
>>> Supraja
>>>
>>
>
> --
> Regards,
> S.SUPRAJA
> MIT
>

Re: Extended Master Secret extension and session ticket reuse

[Susan Hinrichs]

Yes, I believe it should.  ATS doesn't set SSL_OP_NO_EXTENDED_MASTER_SECRET,
and the default is for that feature to be enabled.

Are you having problems with session reuse?  Perhaps the client does not
support the Extended Master secret?

Susan

On Tue, Jul 14, 2020 at 1:26 AM supraja sridhar 
wrote:

> Hello,
>
> Does ATS 7.x support session ticket reuse in the presence of Extended
> Master secret extension in the handshake ?
>
> Thanks
> Supraja
>

Re: ATS and letsencrypt

[Susan Hinrichs]

Interesting.  I'd remove the ssl_ca_name= entirely.  Looking at the code,
it should add the intermediate certs and you tried to do initially.
Apparently that logic isn't working.  I'll try to get a test written for
that.  But in any case, adding the chain certs twice (via the ssl_cert_name
cert and via ssl_ca_name) is not necessary.

On Wed, Mar 11, 2020 at 6:05 PM Jacobo Nájera  wrote:

> El 10/03/20 a las 9:16, Susan Hinrichs escribió:
> > You combine your cert.pem and your chain.pem files and specify that file
> > in the ssl_cert_name attribute.  The specific certificate should go
> > first.  Then the chain certs.
>
> Thanks Susan. It works :)
>
> It tested by sslabs.com tool. It prints me "Incorrect order, Extra
> certs" and Grade A.
>
> My file ssl_multicert.config
>
> ssl_cert_name=cert.pem ssl_key_name=privkey.pem ssl_ca_name=chain.pem
>
> (cert.pem is cert.pem + chain.pem)
>
> How can I fix "Incorrect order, Extra certs"?
>
>
>
>
>
>

Re: ATS and letsencrypt

[Susan Hinrichs]

You combine your cert.pem and your chain.pem files and specify that file in
the ssl_cert_name attribute.  The specific certificate should go first.
Then the chain certs.

On Tue, Mar 10, 2020 at 7:14 AM Jacobo Nájera  wrote:

> Hi,
>
> How can I declarate Let's encrypt certs in ssl_multicert.config?
>
> List of files:
>
> cert.pem
> chain.pem
> fullchain.pem
> privkey.pem
>
> Currently:
>
> ssl_cert_name=cert.pem ssl_key_name=privkey.pem ssl_ca_name=chain.pem
>
>
> Log
>
> [Mar 10 08:04:44.428] {0x7f8186770600} ERROR:
> SSL::140194283456000:error:2006D002:BIO routines:BIO_new_file:system
> lib:../crypto/bio/bss_file.c:78
> [Mar 10 08:04:44.428] {0x7f8186770600} ERROR: failed to load certificate
> chain from /etc/letsencrypt/live/www.domain.com/cert.pem
> [Mar 10 08:04:44.429] {0x7f8186770600} NOTE: failed to reload
> ssl_multicert.config
> [Mar 10 08:04:44.429] {0x7f8186770600} FATAL: failed to load SSL
> certificate file, /etc/trafficserver/ssl_multicert.config
>
>
> Thanks, Jacobo
>

Re: CPU load at idle

[Susan Hinrichs]

Clicking through to the description of the poll_timeout setting gives you a
better description of what is going on.
https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html#proxy-config-net-poll-timeout

If your poll is set too low, your threads will spend very little time
blocking in the poll call, and most of the time spinning between poll
calls.

How are you measuring your CPU load?  Total %CPU over all the CPUs on your
system (e.g. %CPU at the top of your "top" display) or %CPU per computation
unit (e.g. %CPU for your traffic_server process in "top").

On an idle Centos7 box, I see top's reporting of CPU utilization for
traffic_server reported by top at 7.6% but total machine CPU at 0.2%

On Wed, Dec 18, 2019 at 3:37 AM Veiko Kukk  wrote:

> Hi
>
> Before I try anything, I need to understand what it means.
> What does this option do? What polling? net indicates it has something
> to do with network, but what does it poll on network?
>
> Veiko
>
> On Sun, 15 Dec 2019 at 20:25, Shu Kit Chan  wrote:
> >
> > Perhaps try this out? -
> >
> https://docs.trafficserver.apache.org/en/latest/admin-guide/performance/index.en.html#polling-timeout
> >
> > On Fri, Dec 13, 2019 at 6:07 AM Veiko Kukk  wrote:
> > >
> > > Hi
> > >
> > > ATS 7.1.2, Centos 7.7.
> > > I'm seeing 15-16% CPU load while there is no traffic at all.
> > > proxy.process.cache.bytes_used 23934931615744
> > > proxy.process.cache.bytes_total 23935065833472
> > >
> > > Is that normal?
> > >
> > > Veiko
>

Re: Revocation checks on client certificate

[Susan Hinrichs]

No, ATS does not support revocation checks on the client certificate.  By
default it checks that the certificate is signed by a trusted root and is
not expired.  Adding revocation logic is an interesting idea.

There is a hook (TS_EVENT_SSL_VERIFY_CLIENT) where you can you can have
your plugin attach additional logic to verify the client-provided
certificate.
https://docs.trafficserver.apache.org/en/latest/developer-guide/api/types/TSEvent.en.html?highlight=ts_event_ssl_verify_client#c.TS_EVENT_SSL_VERIFY_CLIENT

Looks like this is another place that could use some more documentation.
However, there is a test plugin that exercises the hook
https://github.com/apache/trafficserver/blob/master/tests/tools/plugins/ssl_client_verify_test.cc

On Tue, Dec 3, 2019 at 5:35 AM supraja sridhar 
wrote:

> Hello,
>
> Does ATS perform revocation check on client certificate? Does it support
> CRL and OSCP?
>
> Thanks,
> Supraja
>

Re: Query regarding proxy.config.ssl.client.certification_level

[Susan Hinrichs]

Yes, ip_allow takes a list of IP's.  I think it takes ranges as well.  You
may also need a fqdn value.

No, sni.yaml does not make an appearance until 8.x as
ssl_server_name.yaml.  The file becomes sni.yaml in 9.0.x.

Susan

On Tue, Dec 3, 2019 at 8:23 AM supraja sridhar 
wrote:

> Also, does sni.yaml exist in ATS 7.1.1?
>
> Thanks
> Supraja
>
> On Tue, Dec 3, 2019 at 9:32 AM supraja sridhar 
> wrote:
>
>> Thanks. Will ip_allow take IPs as input. Is the following a valid example
>> ?
>> sni
>> ip_allow: x.y.z.a
>> verify_client: MODERATE
>>
>>
>> On Mon, Nov 25, 2019 at 11:59 PM Susan Hinrichs <
>> shinr...@verizonmedia.com> wrote:
>>
>>> You can specialize the client certificate requirements using sni.yaml.
>>> So only request it for specific domain names.  There is also an ip_allow
>>> action in sni.yaml (which I see is not documented) which would allow to
>>> control requiring client certificate based on the peer's IP.
>>>
>>>
>>> https://docs.trafficserver.apache.org/en/latest/admin-guide/files/sni.yaml.en.html?highlight=sni%20yaml#std:configfile-sni.yaml
>>>
>>> I'll work on putting up a PR with some documentation on the ip_allow
>>> action.
>>>
>>> Susan
>>>
>>> On Sun, Nov 24, 2019 at 11:09 PM supraja sridhar <
>>> suprajasridha...@gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> I understand that -
>>>> proxy.config.ssl.client.certification_level provides the option to
>>>> enable/disable client certificate verification across all connections. Is
>>>> it possible to skip client certificate verification based on source IP?
>>>>
>>>>
>>>> Thanks,
>>>> Supraja
>>>>
>>>
>>
>> --
>> Regards,
>> S.SUPRAJA
>> MIT
>>
>
>
> --
> Regards,
> S.SUPRAJA
> MIT
>

Re: Query regarding proxy.config.ssl.client.certification_level

[Susan Hinrichs]

You can specialize the client certificate requirements using sni.yaml.  So
only request it for specific domain names.  There is also an ip_allow
action in sni.yaml (which I see is not documented) which would allow to
control requiring client certificate based on the peer's IP.

https://docs.trafficserver.apache.org/en/latest/admin-guide/files/sni.yaml.en.html?highlight=sni%20yaml#std:configfile-sni.yaml

I'll work on putting up a PR with some documentation on the ip_allow action.

Susan

On Sun, Nov 24, 2019 at 11:09 PM supraja sridhar 
wrote:

> Hello,
>
> I understand that -
> proxy.config.ssl.client.certification_level provides the option to
> enable/disable client certificate verification across all connections. Is
> it possible to skip client certificate verification based on source IP?
>
>
> Thanks,
> Supraja
>

[proposal] Removing remap thread feature

[SUSAN HINRICHS]

While working on other things, I noticed the feature that sets up dedicated
threads to process remap rules.  Thinking this was remnants of an obsolete
feature, I set up a PR to remove it.
https://github.com/apache/trafficserver/pull/6025

However, in the last steps of setting up that PR, I saw some
documentation.
https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html?highlight=remap%20thread#proxy-config-remap-num-remap-threads

So perhaps the feature is not so obsolete and actually works?

Does anyone use this feature?  If not, is there general agreement to remove
the feature?

Susan

Re: TS_SSL_VERIFY_SERVER_HOOK

[Susan Hinrichs]

That feature was added as TS_SSL_SERVER_VERIFY in 8.0.x.  The name was
normalized to TS_SSL_VERIFY_SERVER_HOOK (to match the naming of
TS_SSL_VERIFY_CLIENT_HOOK) in the branch for 9.0.x.

In theory, that functionality could be backported if you could get the
7.1.x release manager to agree to it, but it would be a significant
backport.  You would probably be better off looking forward to 9.0.x.  A
couple organizations have been working with and improving this
functionality since it was first introduced and the implementation in 9.0.x
should be more resilient.

Susan

On Sun, Nov 17, 2019 at 11:11 PM supraja sridhar 
wrote:

> Hello,
> My organisation currently uses ATS 7.x and are looking for  a
> TS_SSL_VERIFY_SERVER_HOOK
> 
> equivalent in ATS 7.x.
>
> If there are no such hooks in ATS 7.x is it possible to request for a
> backport of this feature for the 7.x version?
>
> Thanks
> Supraja
>

Re: [PROPOSAL] Remove SSL v3 code and configs

[SUSAN HINRICHS]

+1

On Fri, Jun 7, 2019 at 9:52 PM Bryan Call  wrote:

> +1
>
> -Bryan
>
>
> > On Jun 6, 2019, at 5:32 PM, Leif Hedstrom  wrote:
> >
> > This code is disabled and does not build by default. I think it’s time
> to remove this code path completely, it’s an insecure protocol, and I don’t
> think any of us enables this ?
> >
> > — Leif
> >
>
>

Re: SSL Handshake Error with TS 8.0.2 and self signed certificate

[Susan Hinrichs]

I am guessing that your FireFox failure is due to the self-signed
certificate.  The mainstream browsers have been getting more picky.  Does a
GET request work if you use curl with the -k (don't verify server
certificate) argument?

I am more concerned by the crash of your signed certificate.  Could you
share the text output of your certificate?  From the debug messages it
seems that it is failing in the logic that is pulling the names out of the
certificates to enter into the Context map.  Output of "openssl x509 -in
 -text"  or something similar.

Susan

On Sun, Feb 24, 2019 at 4:11 AM Alexander Rabenstein <
alexan...@die-rabensteins.de> wrote:

> Hi,
>
>
>
> I am trying to Setup TS with a self signed certificate as forwarding Proxy
> who should terminate all ssl Connections to origin Servers and then if
> necessary act as ssl Client to the origin Server.
>
>
>
> I created the cert with openssl and also imported in Firefox.
>
>
>
> When I try with openssl as Client I get the following Output:
>
>
>
> ONNECTED(0003)
>
> depth=0 CN = ssst.fritz.box
>
> verify error:num=18:self signed certificate
>
> verify return:1
>
> depth=0 CN = ssst.fritz.box
>
> verify return:1
>
> ---
>
> Certificate chain
>
> 0 s:/CN=ssst.fritz.box
>
>i:/CN=ssst.fritz.box
>
> ---
>
> Server certificate
>
> -BEGIN CERTIFICATE-
>
> MIIFBTCCAu2gAwIBAgIJAOhY4Knu31BbMA0GCSqGSIb3DQEBCwUAMBkxFzAVBgNV
>
> BAMMDnNzc3QuZnJpdHouYm94MB4XDTE5MDIyNDAwMTc0OVoXDTIwMDIyNDAwMTc0
>
> OVowGTEXMBUGA1UEAwwOc3NzdC5mcml0ei5ib3gwggIiMA0GCSqGSIb3DQEBAQUA
>
> A4ICDwAwggIKAoICAQC1BS6l4aya1z/7Z+ZgL8o7qGwXrU0oAr/CEL0vSl8u7JxH
>
> j4QFkPuu1BBzw7MWgVzQtxCs9Igq8SHS6g1HUY9IxeAC+1U3E3uC2cetQTEVerbb
>
> 4EC+zMbzBT6LoGquw96NYkoNW4CLh0CFkHS5Jx9stRNdbi1Y2U6nyo7ijU1JPWYN
>
> /dkDcOoXrxfXqBY8IuJldIXwWjM8A/YNxSr1bTQh9Eta73+OimoWY22a4ScMufLE
>
> r3Grvh3xcXSfuEZzHaag06LfPRiVTdYiD8h1LFHcEno8DJrHTagzHZw5Y/+QtlPr
>
> 4zkSJEw4TwknUyPx0qdSoRo4PTZLUOzXd8t/2bOTLRM3W6WZQ9Wjk4++DmLgFAzh
>
> MC5WLlfn8/B9tZUnTbIbyL1FARc0bNyuWbBMsln/8nrW6XpiPbhlaNVwOX1kgFBX
>
> vyoOsZ4EjXQpzExYcm1G09C/PiiEpBEDzZLSojENgPnvwRjsR4Dswuqc6HxyxEv4
>
> hjXq+MnLrR66n3kZASwQX0DB533kk+bQFkeQ1/VHR0RpOt0hkf4HL70J6+F2e3sR
>
> QqzvFulpaWFl8ZI8XFIvJRDZuCd/MwVskurxVvzof9P31nrb6mSJkgYIlguX+zVi
>
> L6ppvnDtgYIHEmnFq7AbgfAswlH9/z7e234flBfg1Mp9QDlweUvi6w97UugR+wID
>
> AQABo1AwTjAdBgNVHQ4EFgQUyEqcFYmUz0PhwTUsyc1IsryaPBowHwYDVR0jBBgw
>
> FoAUyEqcFYmUz0PhwTUsyc1IsryaPBowDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0B
>
> AQsFAAOCAgEAoRybmMudIuymPWN9PwKD0xah8UvdVBxCQwrV0O9yS7VzqL7zhexh
>
> wvl6148082ORHSuDQogcOukzXKLr4DUBGXE6KcUeLbCuXT3S3RbcJ+D+Or5js467
>
> F66Ov7wu96CUediANqW8+4PBbbDOvmkJb2tqzXoKNbCwWiOy8WmDq19AKmOxb7B8
>
> wW6yPNnoMuXKm3MzioYVVxlzY2dVTlz2ra1chnzchGwNGSZopu6rlCs2fawRAUjE
>
> yGYjWOyvPsGnrAF4J/w13bQsxpHmreLIHTzwUYUk/sIyrNYLwLCpzsx2AyM6kFwC
>
> 3klAWoZ9FOkzFdeeUWPacQG9S5XVfrc0WbanZWawEDoNwn5yg5DfPDBEvg5ocwNL
>
> 6YvRkcGhatNJhT82jU6enCoWNvEO/UG/EP5+rgXgUkxA6KvEsScoK9n/c1PTqISt
>
> 0dQCNyxOSlgaUYpl6Cb8E+ESy2ztO0HjpHVQnQF0jKYQhXM5+6vj5pjKPiD3Os75
>
> PFz9FjD1hjUsNVNiaHxvxjPcK3N3OgbN+66ZaquiC0avZ9u9twRylKtI/mbKmUda
>
> ns9xdhWP5YnnwYm7SCII5pHvdp69tm4tWtjyUxlA5w/YAazhiR5v2uHceKyIOoXB
>
> NckowYPTiPRtM3LGPPf7qYWJB6jDlCL3bGAYSh5vY2fczusCemF/eak=
>
> -END CERTIFICATE-
>
> subject=/CN=ssst.fritz.box
>
> issuer=/CN=ssst.fritz.box
>
> ---
>
> No client certificate CA names sent
>
> Peer signing digest: SHA512
>
> Server Temp Key: ECDH, P-256, 256 bits
>
> ---
>
> SSL handshake has read 2236 bytes and written 415 bytes
>
> ---
>
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
>
> Server public key is 4096 bit
>
> Secure Renegotiation IS supported
>
> Compression: NONE
>
> Expansion: NONE
>
> No ALPN negotiated
>
> SSL-Session:
>
> Protocol  : TLSv1.2
>
> Cipher: ECDHE-RSA-AES256-GCM-SHA384
>
> Session-ID:
> 7BB8424C6E8024BD53629BA955FD8F6D7EBFBE9D93F1F04D7714DF807AF37396
>
> Session-ID-ctx:
>
> Master-Key:
> 2BEC5E965363094EEAF067E098EE817654AC8653040A4A0321F140642C395DC43E72FB3C9FED44E9F65397ECC0D10B60
>
> Key-Arg   : None
>
> Krb5 Principal: None
>
> PSK identity: None
>
> PSK identity hint: None
>
> TLS session ticket lifetime hint: 300 (seconds)
>
> TLS session ticket:
>
>  - 0f 05 62 e6 0d 6b 7e d0-c4 12 a8 72 1a 4d 13 e7
> ..b..k~r.M..
>
> 0010 - 77 6c 20 32 42 96 d3 49-4e cc 29 ca a9 e8 95 ef   wl
> 2B..IN.).
>
> 0020 - 13 69 6f 31 63 74 f4 1f-c6 62 54 11 5a a9 ff 62
> .io1ct...bT.Z..b
>
> 0030 - 5c b1 d3 9f 3e 9f 16 e5-0b 25 c8 e4 de 6c 00 fd
> \...>%...l..
>
> 0040 - 79 c4 07 c3 4b b8 8d cd-de c7 dc a9 b6 c7 ce 06
> y...K...
>
> 0050 - a3 1f 39 3d b2 9b ab 39-2d da 4d f5 bc b8 96 aa
> ..9=...9-.M.
>
> 0060 - 52 d0 67 34 84 5b b9 c0-1c 0d d3 4d 6a 97 33 ac
> R.g4.[.Mj.3.
>
> 0070 - aa 9f 73 ef 0a c4 41 87-0c 43 98 48 4c f6 e7 5a
> ..s...A..C.HL..Z
>
> 0080 - 77 ff 3c 8e 8b 61 3b 8f-59 cc fa fb 13 73 68 14
> w.<..a;.Ysh.
>
> 0090 - f7 89 fa b2 6f 9d fb e6-d5 12 5e a2 11 bd a8 

Re: Cannot proxy to site HTTPS on port 8443

[Susan Hinrichs]

If you are proxying through ATS instead of terminating the TLS on the ATS
box, you will need to update the set of allowed connect_ports

proxy.config.http.connect_ports


https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html?highlight=connect_ports#proxy.config.http.connect_ports

On Thu, Feb 21, 2019 at 1:23 PM Eric Chaves  wrote:

> Hi folks,
>
> I've successfully configured an ATS instance working as forward proxy for
> my services. My client applications are successfully using the proxy to
> reach sites running on standard HTTP ports (80 and 443) but when I try to
> reach a site in non standard site (ie https://some-domain:8443/index.html)
> I receive an error " Received HTTP code 403 from proxy after CONNECT". The
> HTTP response headers are:
>
> HTTP/1.1 403 Tunnel Forbidden
> Date: Thu, 21 Feb 2019 19:20:27 GMT
> Proxy-Connection: keep-alive
> Server: ATS/8.0.2
> Cache-Control: no-store
> Content-Type: text/html
> Content-Language: en
> Content-Length: 207
>
> If I ssh into the proxy host and perform a simple curl to the site
> destination (ie curl https://some-domain:8443/index.html) I successfully
> reach it, so I assume I'm missing something in ATS configuration.
>
> Any idea what I could be doing wrong?
>
> Best regards,
>
> Eric
>

Re: Looking for opinions on additions to ssl_server_name.yaml

[Susan Hinrichs]

Ok.  I didn't know how to do lists in yaml.  I think you will still want to
specify and enable list or a disable list depending on the use case.  It is
highly unlikely that you will want an "all" option.  Many of the old, old
protocols should never be enabled.

On Mon, Nov 19, 2018 at 4:31 PM Alan Carroll 
wrote:

> I don't like either. I'd prefer "tls-enable: [ 1_0, 1_1, 1_2, 1_3 ]" with
> the special case of "tls-enable: all" where if it's not enabled, it's
> disabled. Or, if separate flags, "tls_1_3: enable/disable" in which case
> the protocol levels are enabled by default.
>
> On Mon, Nov 19, 2018 at 4:11 PM Susan Hinrichs 
> wrote:
>
>> We currently have the ability to turn off HTTP/2 support on a per domain
>> basis via the disable_h2 option in ssl_server_name.yaml
>>
>>
>> https://docs.trafficserver.apache.org/en/latest/admin-guide/files/ssl_server_name.yaml.en.html
>>
>> Folks have asked for a similar mechanism to not offer TLS protocols (e.g.
>> 1.3) for specific domain names.  I can see use cases for adding or removing
>> from the default in records.config for very new protocols (e.g. the phone
>> app for a domain doesn't handle TLSv1.3) or very old protocols (e.g. some
>> critical set top boxes can only use TLSv1.0).
>>
>> We could have a separate toggle for each protocol.  Directly mapping what
>> is in records.config.
>>
>> - fqdn: bob.com
>>   enable_tls_v1_3: true/false
>>
>> Or we could try to have a list entry
>>
>> -fqdn: bob.com
>>   enable_tls_protocols:
>> - tls_v1_3
>> - tls_v1_2
>>   disable_tls_protocols:
>> -tls_v1.0
>>
>> Please share your opinions.
>>
>>
>
> --
> *Beware the fisherman who's casting out his line in to a dried up
> riverbed.*
> *Oh don't try to tell him 'cause he won't believe. Throw some bread to the
> ducks instead.*
> *It's easier that way. *- Genesis : Duke : VI 25-28
>

Looking for opinions on additions to ssl_server_name.yaml

[Susan Hinrichs]

We currently have the ability to turn off HTTP/2 support on a per domain
basis via the disable_h2 option in ssl_server_name.yaml

https://docs.trafficserver.apache.org/en/latest/admin-guide/files/ssl_server_name.yaml.en.html

Folks have asked for a similar mechanism to not offer TLS protocols (e.g.
1.3) for specific domain names.  I can see use cases for adding or removing
from the default in records.config for very new protocols (e.g. the phone
app for a domain doesn't handle TLSv1.3) or very old protocols (e.g. some
critical set top boxes can only use TLSv1.0).

We could have a separate toggle for each protocol.  Directly mapping what
is in records.config.

- fqdn: bob.com
  enable_tls_v1_3: true/false

Or we could try to have a list entry

-fqdn: bob.com
  enable_tls_protocols:
- tls_v1_3
- tls_v1_2
  disable_tls_protocols:
-tls_v1.0

Please share your opinions.

Re: trafficserver 8 - Logging Client request (domain)

[Susan Hinrichs]

Do you have any error messages in diags.log, error.log, or traffic.out?
Our organization doesn't use that field, but perhaps there is a bug in its
support.  I'll try to sent that up on a test box today.

On Sun, Nov 18, 2018 at 1:31 AM Sevan Gelici  wrote:

> Hello,
>
> I dont know if its a issue or if i do it wrong but logging in
> trafficserver 8.0 doesnt work well for me. When i add to
> "/etc/trafficserver/logging.yaml" the value  %  its not giving me
> output anymore.
>
> In the default logging.yaml i modified this part
> logs:
> - filename: squid
>   format: welf
>   mode: ascii
> this works but when i modify as example % to % it doesnt work
> anymore.
>
> Could someone explain why it doesnt log anymore after giving these value?
>
>
> -
> https://ats-zh.readthedocs.io/en/latest/admin/event-logging-formats.en.html#custom-logging-fields
> - http://trafficserver.apache.org/logbuilder/
>
>
> Kind regards,
>
> Sevan Gelici
>

Re: Traffic server suddenly drop the packets and crashed

[Susan Hinrichs]

You probably want to extend your ip_local_port range to 1025 to 65535.  I
assume you have an application that requires the reserved ports.

When you run your test, what is the output of "ss -s" ?  Is the number of
ports in TIME_WAIT really high?



On Fri, Nov 16, 2018 at 8:43 AM Vasanth Mathivanan <
vasant...@evolutiondigital.com> wrote:

> Yes , its generating core dump  file in traffic server root path and we
> are using ATS.6.2 in centos 6.5.
>
> traffic.out logs
>
> *“ATAL: InkAPI.cc:1879: failed assert `sdk_sanity_check_mbuffer(bufp) ==
> TS_SUCCESS`*
>
> *traffic_server: using root directory '/opt/trafficserver'*
>
> *traffic_server: received signal 6 (Aborted)*
>
> *traffic_server - STACK TRACE: *
>
>
> */opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x8e)[0x4ac5ee]*
>
> */lib64/libpthread.so.0[0x3030e0f7e0]*
>
> */lib64/libc.so.6(gsignal+0x35)[0x3030a32495]*
>
> */lib64/libc.so.6(abort+0x175)[0x3030a33c75]*
>
> */opt/trafficserver/lib/libtsutil.so.6(+0x28228)[0x2b5cb60dc228]*
>
> */opt/trafficserver/lib/libtsutil.so.6(+0x282bc)[0x2b5cb60dc2bc]*
>
> */opt/trafficserver/lib/libtsutil.so.6(+0x26595)[0x2b5cb60da595]*
>
> */opt/trafficserver/bin/traffic_server(TSHandleMLocRelease+0x3a)[0x4c33ca]*
>
>
> */opt/trafficserver/libexec/trafficserver/stale_while_revalidate.so(+0x38c9)[0x2b5e9eaa48c9]*
>
>
> */opt/trafficserver/bin/traffic_server(_ZN15INKContInternal12handle_eventEiPv+0xdb)[0x4c12ab]*
>
>
> */opt/trafficserver/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x1b7)[0x5ac967]*
>
>
> */opt/trafficserver/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x65b)[0x5b226b]*
>
>
> */opt/trafficserver/bin/traffic_server(_ZN6HttpSM22state_cache_open_writeEiPv+0x20e)[0x5a3cde]*
>
>
> */opt/trafficserver/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xca)[0x5b3f3a]*
>
>
> */opt/trafficserver/bin/traffic_server(_ZN11HttpCacheSM22state_cache_open_writeEiPv+0x281)[0x58a481]*
>
>
> */opt/trafficserver/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x120)[0x766f00]*
>
>
> */opt/trafficserver/bin/traffic_server(_ZN7EThread7executeEv+0x811)[0x767bd1]*
>
> */opt/trafficserver/bin/traffic_server[0x76698a]*
>
> */lib64/libpthread.so.0[0x3030e07aa1]*
>
> */lib64/libc.so.6(clone+0x6d)[0x3030ae8bdd]”*
>
>
>
> No I did not set ephemeral ports .
>
>
> Had default values already .
>
> net.ipv4.ip_local_port_range = 32768 60999
>
> net.ipv4.ip_local_reserved_ports =###this one is empty
>
>
>
> So its set by manually .
>
> net.ipv4.ip_local_reserved_ports = 3-31000
>
>
>
> Is this ok ? .
>
>
>
>
> __Vasanth
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Susan Hinrichs 
> *Sent: *Friday, November 16, 2018 7:55 PM
> *To: *users@trafficserver.apache.org
> *Subject: *Re: Traffic server suddenly drop the packets and crashed
>
>
> Are you exhausting ephemeral ports?  What is the output of  "ss -s" on
> your Traffic Server machine? That is quite easy exhaust all of the
> ephemeral ports for a single load testing client machine between active and
> time-wait connections.
>
> Is Traffic Server generating a core or a stack trace?  What version of
> Traffic Server?
>
> On Fri, Nov 16, 2018 at 1:42 AM Vasanth Mathivanan <
> vasant...@evolutiondigital.com> wrote:
>
>> Hi ,
>>
>> We are testing 1000 client access one by one load test after  700 clients
>> dropping the packets like “connection timeout” or “Connection reset by
>> peer ” errors .
>>
>>
>>
>> Ram and Cpus resources are everything is fine .Ethernet speed also 20gb/s
>> both client  and traffic server  . Origin server has 2gb/s speed between
>> ATS and Origin server .While running 700 requests in origin server content
>> will be  receiving speed less than 10Mb/s then traffic server and client
>> getting more than 1Gb/s speed .
>>
>>
>>
>> We are also monitoring that resources everything running fine but crashed
>> the traffic server after 700 requests  .
>>
>>
>>
>> Note: We are created Java player , We will give the no of  requests its
>> call the particular URL based on given requests .
>>
>>
>>
>> __Vasanth
>>
>>
>>
>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
>> Windows 10
>>
>>
>>
>

Re: Traffic server suddenly drop the packets and crashed

[Susan Hinrichs]

Are you exhausting ephemeral ports?  What is the output of  "ss -s" on your
Traffic Server machine? That is quite easy exhaust all of the ephemeral
ports for a single load testing client machine between active and time-wait
connections.

Is Traffic Server generating a core or a stack trace?  What version of
Traffic Server?

On Fri, Nov 16, 2018 at 1:42 AM Vasanth Mathivanan <
vasant...@evolutiondigital.com> wrote:

> Hi ,
>
> We are testing 1000 client access one by one load test after  700 clients
> dropping the packets like “connection timeout” or “Connection reset by
> peer ” errors .
>
>
>
> Ram and Cpus resources are everything is fine .Ethernet speed also 20gb/s
> both client  and traffic server  . Origin server has 2gb/s speed between
> ATS and Origin server .While running 700 requests in origin server content
> will be  receiving speed less than 10Mb/s then traffic server and client
> getting more than 1Gb/s speed .
>
>
>
> We are also monitoring that resources everything running fine but crashed
> the traffic server after 700 requests  .
>
>
>
> Note: We are created Java player , We will give the no of  requests its
> call the particular URL based on given requests .
>
>
>
> __Vasanth
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>

Re: [VOTE] Release Apache Traffic Server 7.1.5 (RC0)

[Susan Hinrichs]

Sounds like the issue fixed in
https://github.com/apache/trafficserver/pull/4538

If the Docker container is not run with sufficient privilege (IPC and
NETADMIN in addition to NETBIND), traffic server would fail to start up.
Although you state this worked in previous versions on 7.1.  The code I
changed in this PR had not changed for several years.

On Sun, Nov 11, 2018 at 4:15 PM Leif Hedstrom  wrote:

>
>
> > On Nov 12, 2018, at 4:26 AM, ezko  wrote:
> >
> > Hi,
> > i'm trying to run this within docker but it's not working.
> > What am I doing wrong ?
>
>
> hard to tell from this, but looks like traffic_manager or traffic_serve is
> not starting up. Can you try running either of those “manually” inside the
> Docker instance, and see if it produces anything? Also, check the logs to
> see if it says why it can’t start up?
>
> — Leif
>
>

Re: [PROPOSAL] HTTP Metrics Overhaul

[Susan Hinrichs]

I completely agree with the stats re-normalizing.  I've been messed up
multiple times by assuming that a http metric covers both protocols but was
in fact http/1.x specific.

On Tue, Oct 16, 2018 at 12:44 PM Bryan Call  wrote:

> The proxy.process.https stats (only 2 stats) should also be considered
> when overhauling the stats.  They are really TLS or non-TLS stats and not
> tied to the scheme.  I recommend breaking up TLS and non-TLS metric and
> calling them proxy.process.ssl. and proxy.process.non-ssl.
>
> Another option to build a hierarchy of stats and have it be
> proxy.process.encryption.http_version.scheme (e.g.
> proxy.process.{ssl,non-ssl}.{http1,http2}.{http,https}). Where scheme I
> don’t see being used very much or at all, so it would only be mainly
> encryption and http_version.  For http2 encryption would always be ssl.
>
> Also, I would be for modernizing the stats and configuration and calling
> everything tls instead of ssl.
>
> -Bryan
>
>
>
> On Oct 15, 2018, at 7:23 PM, Masaori Koshiba  wrote:
>
> Hi all,
>
> I’d like to propose some HTTP metrics changes. Because current HTTP
> metrics doesn’t have consistent naming rules.
>
> 
> 1. Define `proxy.process.http.*` is HTTP version general metrics.
> 2. Introduce `proxy.process.http1.*` metrics for HTTP/1.1 specific metrics.
> 3. Split general metric into version specific metrics if needed.
> 
>
> More details are in
> - https://github.com/apache/trafficserver/issues/4415
> -
> https://docs.google.com/spreadsheets/d/1zux3OPiDNJlWALluhr8ciKypg_sYVxbG9fdmeuDD-Bo/edit?usp=sharing
>
> My proposal has incompatible changes. And it requires some actions to
> people who is tracking these metrics.
> Please comment on the issue or this thread if you have any opinions.
>
> My current target of these incompatible changes are next major release
> (9.0.0).
>
> Thanks,
> Masaori
>
>
>

Re: Failover Scenario in Trafficserver

[Susan Hinrichs]

Another option is to place several Traffic Server boxes behind a VIP, i.e.
a router or load balancer that owns a common IP and distributes connections
to whichever Traffic Server box is alive.  A router capable of basic ECMP
routing can mostly do this.  Or a dedicated state-aware load balancer can
detect that a Traffic Server box has gone done and send new connections to
other servers.

On Wed, Oct 10, 2018 at 8:19 AM Fieck, Brennan 
wrote:

> I believe what he's saying is that this behaviour is up to the client. The
> client will try to connect to one traffic server, and if it fails then the
> client just needs to know the URL/IP of the secondary server and try that -
> without any direction from Traffic Server.
> It makes sense, because in a failure scenario you can't rely on the
> Traffic Server to be working properly, so the safest thing to do is handle
> it yourself if possible.
> --
> *From:* Vasanth Mathivanan 
> *Sent:* Tuesday, October 9, 2018 10:26 PM
> *To:* users@trafficserver.apache.org
> *Subject:* [EXTERNAL] RE: Failover Scenario in Trafficserver
>
>
> Yes , exactly how it will make on client side without traffic controller ?
>
> could you please explain ?
>
> _Vasanth
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> *From: *Patrick O'Brien 
> *Sent: *Tuesday, October 9, 2018 7:55 PM
> *To: *users@trafficserver.apache.org
> *Subject: *Re: Failover Scenario in Trafficserver
>
>
> We have this configured on the client side, e.g if the client connection
> to trafficserver001 fails the client will attempt a connection to
> trafficserver002.
>
> -patrick
>
> On Mon, Oct 8, 2018 at 10:17 PM Vasanth Mathivanan <
> vasant...@evolutiondigital.com> wrote:
>
>> Hi All ,
>>
>>
>>
>> How to switch failover traffic server to another traffic server, example
>> we have two traffic server both points to domain (points to two ips using
>> round robin) I had been  access only one traffic server in client side  if
>>  fails the first traffic server  to switch another traffic server(i.e.
>> second traffic server ) , Could you please explain  how to configure this
>> type of scenario ?
>>
>>
>>
>>
>>
>>
>>
>> _Vasanth
>>
>>
>>
>> Sent from Mail  for
>> Windows 10
>>
>>
>>
>

Re: ATS and TLS close-notify

[Susan Hinrichs]

True the change in behavior between 6.x and 7.x is concerning.  The basic
half-open logic hasn't changed as far as I know.  There is one H2 change on
master, but that is not on the 7.1.x branch (just checked).  There may be
some tweaky little change.  Or it may be something else entirely.

On Sun, Sep 2, 2018 at 11:51 AM, Leif Hedstrom  wrote:

> That seems plausible , but isn’t the indication that things got a lot
> worse from v6.x to 7.x?
>
> The half close logic is old, isn’t it? Did we change something into it in
> 7.x?
>
> — Leif
>
> On Sep 2, 2018, at 07:35, Susan Hinrichs  wrote:
>
> Thinking on this some more, this sounds like bad interactions with the TCP
> half closed logic in the state machine. If you are doing HTTP 1 over
> non-TLS, it is legal for a client to send a FIN but then read more data
> that the server sends. There is some logic to turn off this half close
> logic in traffic server in inappropriate cases but it is not perfect and
> has varied over time.
>
> Earlier this year there was a PR to add a knob to turn off this behavior,
> but I don't know where it landed. I will check that out when I get back to
> the office.
>
> Susan
>
> On Sat, Sep 1, 2018, 5:56 PM Susan Hinrichs  wrote:
>
>> Yes, ATS should respond with close notify or at least FIN the connection.
>> What version of ATS are you seeing this with?
>>
>> If there was already an application data packet in flight, it may arrive
>> after the client sends the close notify. But in general ATS should shut
>> down the connection.
>>
>> On Fri, Aug 31, 2018, 11:31 PM Jeremy Payne  wrote:
>>
>>> Context:
>>>
>>> Openssl 102k
>>> ATS 714
>>>
>>> I notice that at times a client will send a TLS 1.2 close-notify,
>>> immediately followed by a FIN-ACK. Which seems to be following spec.
>>>
>>> "It is not required for the initiator of the close to wait for the
>>> responding close_notify alert before
>>>closing the read side of the connection."
>>>
>>>
>>> However, in response, ATS continuous to send 'application data'
>>> instead of issuing its own TLS 1.2 close-notify. Which then results in
>>> connections lingering waiting for an ACK back from the client.
>>> Which will never come, since per spec:
>>>
>>> "Any data received after a closure alert is ignored."
>>>
>>>
>>> Is ATS still within TLS 1.2 spec by continuing to send application
>>> data, even though the client sent a close notify ?
>>>
>>> I tested some other https servers compiled against openssl 102k, and I
>>> see a close notify sent by the client, with the https server
>>> responding with it's own close notify.
>>>
>>> Thanks!
>>>
>>

Re: ATS and TLS close-notify

[Susan Hinrichs]

Thinking on this some more, this sounds like bad interactions with the TCP
half closed logic in the state machine. If you are doing HTTP 1 over
non-TLS, it is legal for a client to send a FIN but then read more data
that the server sends. There is some logic to turn off this half close
logic in traffic server in inappropriate cases but it is not perfect and
has varied over time.

Earlier this year there was a PR to add a knob to turn off this behavior,
but I don't know where it landed. I will check that out when I get back to
the office.

Susan

On Sat, Sep 1, 2018, 5:56 PM Susan Hinrichs  wrote:

> Yes, ATS should respond with close notify or at least FIN the connection.
> What version of ATS are you seeing this with?
>
> If there was already an application data packet in flight, it may arrive
> after the client sends the close notify. But in general ATS should shut
> down the connection.
>
> On Fri, Aug 31, 2018, 11:31 PM Jeremy Payne  wrote:
>
>> Context:
>>
>> Openssl 102k
>> ATS 714
>>
>> I notice that at times a client will send a TLS 1.2 close-notify,
>> immediately followed by a FIN-ACK. Which seems to be following spec.
>>
>> "It is not required for the initiator of the close to wait for the
>> responding close_notify alert before
>>closing the read side of the connection."
>>
>>
>> However, in response, ATS continuous to send 'application data'
>> instead of issuing its own TLS 1.2 close-notify. Which then results in
>> connections lingering waiting for an ACK back from the client.
>> Which will never come, since per spec:
>>
>> "Any data received after a closure alert is ignored."
>>
>>
>> Is ATS still within TLS 1.2 spec by continuing to send application
>> data, even though the client sent a close notify ?
>>
>> I tested some other https servers compiled against openssl 102k, and I
>> see a close notify sent by the client, with the https server
>> responding with it's own close notify.
>>
>> Thanks!
>>
>

Re: ATS and TLS close-notify

[Susan Hinrichs]

I'd have to dig in some more, but a quick look at the commit you referenced
I don't think would cause what Jeremy is describing.  It is an addition to
do_io_close.  At that point ATS will at least send a FIN and will possibly
send a close-notify.  It will not continue to send data.

On Sat, Sep 1, 2018 at 6:29 PM, Chou, Peter  wrote:

> Susan,
>
>
>
> The problem below is reported against 7.1.4. As background, we believe
> that the “lingering connections” situation described below is either
> causing or contributing to the number of connections on the server to
> increase. We see that nearby 6.2.1 nodes under similar load would see a
> smaller increase in the number of connections compared to 7.1.4. Is it
> possible that changes between 6.2.1 and 7.1.4 may have an effect such as
> the tuning done towards calling SSL_shutdown() in commit 0ab449? Appreciate
> any insights.
>
>
>
> Thanks,
>
> Peter
>
>
>
>
>
> *From:* Susan Hinrichs [mailto:shinr...@oath.com]
> *Sent:* Saturday, September 01, 2018 3:57 PM
> *To:* users@trafficserver.apache.org
> *Subject:* Re: ATS and TLS close-notify
>
>
>
> Yes, ATS should respond with close notify or at least FIN the connection.
> What version of ATS are you seeing this with?
>
>
>
> If there was already an application data packet in flight, it may arrive
> after the client sends the close notify. But in general ATS should shut
> down the connection.
>
>
>
> On Fri, Aug 31, 2018, 11:31 PM Jeremy Payne  wrote:
>
> Context:
>
> Openssl 102k
> ATS 714
>
> I notice that at times a client will send a TLS 1.2 close-notify,
> immediately followed by a FIN-ACK. Which seems to be following spec.
>
> "It is not required for the initiator of the close to wait for the
> responding close_notify alert before
>closing the read side of the connection."
>
>
> However, in response, ATS continuous to send 'application data'
> instead of issuing its own TLS 1.2 close-notify. Which then results in
> connections lingering waiting for an ACK back from the client.
> Which will never come, since per spec:
>
> "Any data received after a closure alert is ignored."
>
>
> Is ATS still within TLS 1.2 spec by continuing to send application
> data, even though the client sent a close notify ?
>
> I tested some other https servers compiled against openssl 102k, and I
> see a close notify sent by the client, with the https server
> responding with it's own close notify.
>
> Thanks!
>
>

Re: ATS and TLS close-notify

[Susan Hinrichs]

Yes, ATS should respond with close notify or at least FIN the connection.
What version of ATS are you seeing this with?

If there was already an application data packet in flight, it may arrive
after the client sends the close notify. But in general ATS should shut
down the connection.

On Fri, Aug 31, 2018, 11:31 PM Jeremy Payne  wrote:

> Context:
>
> Openssl 102k
> ATS 714
>
> I notice that at times a client will send a TLS 1.2 close-notify,
> immediately followed by a FIN-ACK. Which seems to be following spec.
>
> "It is not required for the initiator of the close to wait for the
> responding close_notify alert before
>closing the read side of the connection."
>
>
> However, in response, ATS continuous to send 'application data'
> instead of issuing its own TLS 1.2 close-notify. Which then results in
> connections lingering waiting for an ACK back from the client.
> Which will never come, since per spec:
>
> "Any data received after a closure alert is ignored."
>
>
> Is ATS still within TLS 1.2 spec by continuing to send application
> data, even though the client sent a close notify ?
>
> I tested some other https servers compiled against openssl 102k, and I
> see a close notify sent by the client, with the https server
> responding with it's own close notify.
>
> Thanks!
>

Re: What is the best way to scale ATS?

[Susan Hinrichs]

We use a load balancer in front of our clusters of ATS servers to scale
horizontally.  You could also just leverage ECMP routing in your router to
similarly distribute connections (plus some extra work to deal with servers
coming up and down).We have a proprietary CARP plugin to share cached
data between servers.  Moving forward I think that logic is being folded
into the next hop logic, parent selection logic.

On Mon, Jul 23, 2018 at 5:34 AM, Sean G  wrote:

> Hi Everyone,
>
> Second post, so still very new (but loving it!) to ATS. I see that
> clustering support was removed in ATS 7 and I'm wondering how people now
> scale ATS ?
>
> I have a single instance at the moment which is likely to hit its limits on
> bandwidth before anything else. Is it possible to horizontally scale ATS or
> is it best to use transitional load balances in front of ATS? I'm mainly
> interested in scaling up resources (bandwidth) but also interested in
> resilience as aside benefit.
>
> Many thanks.
>
>
>
> --
> Sent from: http://apache-traffic-server.24303.n7.nabble.com/
>

Re: Connection rejected for MTLS forward proxy

[Susan Hinrichs]

You cannot try 7.1.x in your test environment?

On Thu, Feb 22, 2018 at 11:00 AM, salil GK <gksa...@gmail.com> wrote:

> It would be a big task to change the ATS to 7.x in my server and do the
> test. And this particular issue actually happened in our production
> environment.
>
> Thanks
> ~S
>
> On 22 February 2018 at 22:16, Susan Hinrichs <shinr...@oath.com> wrote:
>
>> Alan also pointed out that you are running ATS 6.x.  Could you try your
>> test scenario on ATS 7.1.2?  We've made considerable cleanup on the TLS
>> handshake and more debugging in the client cert verification.
>>
>> Looking at your pcap file and your logs, it appears that the certs are
>> being exchanged.  Both the server and the client certs are signed by the
>> same entities so setting the same CA files makes sense.
>>
>>
>>
>> On Thu, Feb 22, 2018 at 10:17 AM, Persia Aziz <persia.a...@yahoo.com>
>> wrote:
>>
>>> ``CONFIG proxy.config.ssl.client.verify.server INT 0'' is disabling
>>> origin server certificate verification(i.e., when ATS initiates handshake
>>> to the origin server). From the configs you specified in this email, looks
>>> like you want the client cert to be verified by ATS. I have attached a
>>> screenshot of wireshark and ATS logs capturing ssl handshake where the
>>> client cert verification fails.
>>> Syeda Persia Aziz
>>> Software Developer
>>> Yahoo! Inc.
>>> Champaign, Illinois
>>>
>>>
>>> On Thursday, February 22, 2018, 9:05:27 AM CST, salil GK <
>>> gksa...@gmail.com> wrote:
>>>
>>>
>>> I wanted to have MTLS proxy. Hence we have to have client cert
>>> verification in server side. So  proxy.config.ssl.client.CA.cert.filename
>>> and proxy.config.ssl.client.CA.cert.path are set
>>> I have verified tomcat certificate ( which is what client is using for
>>> connection ) using ca.pem in the server and they are good.
>>>
>>>
>>>
>>> On Feb 22, 2018 7:49 PM, "Susan Hinrichs" <shinr...@oath.com> wrote:
>>>
>>> I would assume that your CA files are not set correctly for ATS to
>>> verify the origin certificates sent to it.  proxy.config.ssl.client.CA.
>>> cert.filename and proxy.config.ssl.client.CA. cert.path.  If you don't
>>> care about having ATS verify the origin certificates, you can leave the
>>> proxy.config.ssl.client. verify.server set to 0.
>>>
>>> On Thu, Feb 22, 2018 at 5:46 AM, salil GK <gksa...@gmail.com> wrote:
>>>
>>> I have set client server verification to 'no'
>>>
>>> CONFIG proxy.config.ssl.client.verify .server INT 0
>>>
>>> and this time things went fie and ATS worked as forward proxy.
>>> So looks like client verification failure in server side only I guess ?
>>>
>>> Thanks
>>> ~S
>>>
>>> On 22 February 2018 at 01:14, Susan Hinrichs <shinr...@oath.com> wrote:
>>>
>>> It looks like in this exchange the client did not send a client
>>> certificate.  But the other exchanges in the log file don't have the "
>>> ssl3_get_client_certificate:p eer did not return a certificate"
>>> message.  So perhaps one test exchange had the client certificate missing.
>>>
>>> The server certificate is being selected, so I assume the server
>>> certificate message is being sent back to the client.
>>>
>>> On Wed, Feb 21, 2018 at 1:11 PM, Alan Carroll <solidwallofc...@oath.com>
>>> wrote:
>>>
>>> This looks like the important part of the logs (you can drop by my desk
>>> for further detail if you want, Susan & Persia). AFAICT this covers an
>>> entire transaction. I checked the start up messages and saw no errors, but
>>> I did not see any mention of 'ca.pem'. Is there some typo in his
>>> configuration? Is the ATS version too old to support client certificate
>>> verification? I'm beginning to suspect that.
>>>
>>> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
>>> {0x7fd7da831740} DEBUG:  (ssl)
>>> [SSLNextProtocolAccept:mainEve nt] event 202 netvc 0x5567d9e4aca0
>>> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
>>> {0x7fd7da831740} DEBUG: 
>>> (ssl) IP context is (nil) for [XXX.XXX.XXX.33:34686] ->
>>> [XXX.XXX.XXX.XXX:8445], default context 0x5567d9bcf430
>>> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
>>> {0x7fd7da831740} 

Re: Connection rejected for MTLS forward proxy

[Susan Hinrichs]

Alan also pointed out that you are running ATS 6.x.  Could you try your
test scenario on ATS 7.1.2?  We've made considerable cleanup on the TLS
handshake and more debugging in the client cert verification.

Looking at your pcap file and your logs, it appears that the certs are
being exchanged.  Both the server and the client certs are signed by the
same entities so setting the same CA files makes sense.



On Thu, Feb 22, 2018 at 10:17 AM, Persia Aziz <persia.a...@yahoo.com> wrote:

> ``CONFIG proxy.config.ssl.client.verify.server INT 0'' is disabling
> origin server certificate verification(i.e., when ATS initiates handshake
> to the origin server). From the configs you specified in this email, looks
> like you want the client cert to be verified by ATS. I have attached a
> screenshot of wireshark and ATS logs capturing ssl handshake where the
> client cert verification fails.
> Syeda Persia Aziz
> Software Developer
> Yahoo! Inc.
> Champaign, Illinois
>
>
> On Thursday, February 22, 2018, 9:05:27 AM CST, salil GK <
> gksa...@gmail.com> wrote:
>
>
> I wanted to have MTLS proxy. Hence we have to have client cert
> verification in server side. So  proxy.config.ssl.client.CA.cert.filename
> and proxy.config.ssl.client.CA.cert.path are set
> I have verified tomcat certificate ( which is what client is using for
> connection ) using ca.pem in the server and they are good.
>
>
>
> On Feb 22, 2018 7:49 PM, "Susan Hinrichs" <shinr...@oath.com> wrote:
>
> I would assume that your CA files are not set correctly for ATS to verify
> the origin certificates sent to it.  proxy.config.ssl.client.CA.
> cert.filename and proxy.config.ssl.client.CA. cert.path.  If you don't
> care about having ATS verify the origin certificates, you can leave the
> proxy.config.ssl.client. verify.server set to 0.
>
> On Thu, Feb 22, 2018 at 5:46 AM, salil GK <gksa...@gmail.com> wrote:
>
> I have set client server verification to 'no'
>
> CONFIG proxy.config.ssl.client.verify .server INT 0
>
> and this time things went fie and ATS worked as forward proxy.
> So looks like client verification failure in server side only I guess ?
>
> Thanks
> ~S
>
> On 22 February 2018 at 01:14, Susan Hinrichs <shinr...@oath.com> wrote:
>
> It looks like in this exchange the client did not send a client
> certificate.  But the other exchanges in the log file don't have the "
> ssl3_get_client_certificate:p eer did not return a certificate" message.
> So perhaps one test exchange had the client certificate missing.
>
> The server certificate is being selected, so I assume the server
> certificate message is being sent back to the client.
>
> On Wed, Feb 21, 2018 at 1:11 PM, Alan Carroll <solidwallofc...@oath.com>
> wrote:
>
> This looks like the important part of the logs (you can drop by my desk
> for further detail if you want, Susan & Persia). AFAICT this covers an
> entire transaction. I checked the start up messages and saw no errors, but
> I did not see any mention of 'ca.pem'. Is there some typo in his
> configuration? Is the ATS version too old to support client certificate
> verification? I'm beginning to suspect that.
>
> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
> {0x7fd7da831740} DEBUG:  (ssl)
> [SSLNextProtocolAccept:mainEve nt] event 202 netvc 0x5567d9e4aca0
> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
> {0x7fd7da831740} DEBUG: 
> (ssl) IP context is (nil) for [XXX.XXX.XXX.33:34686] ->
> [XXX.XXX.XXX.XXX:8445], default context 0x5567d9bcf430
> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
> {0x7fd7da831740} DEBUG:  (ssl)
> ssl_callback_info ssl: 0x5567d9a86d30 where: 16 ret: 1
> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
> {0x7fd7da831740} DEBUG:  (ssl)
> ssl_callback_info ssl: 0x5567d9a86d30 where: 8193 ret: 1
> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
> {0x7fd7da831740} DEBUG:  (ssl)
> set_context_cert ssl=0x5567d9a86d30 server=gmt-dvor-vcsc1.cisco.co m
> <http://gmt-dvor-vcsc1.cisco.com> handshake_complete=0
> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
> {0x7fd7da831740} DEBUG:  (ssl)
> ssl_cert_callback found SSL context 0x5567d9bcf430 for requested name '
> gmt-dvor-vcsc1.cisco.com'
> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
> {0x7fd7da831740} DEBUG:  (ssl)
> callHooks sslHandshakeHookState=0
> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
> {0x7fd7da831740} DEBUG:  (ssl)
> ssl_callback_info ssl: 0x5567d9a86d30 where: 8193 ret: 1
> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
>

Re: Connection rejected for MTLS forward proxy

[Susan Hinrichs]

I would assume that your CA files are not set correctly for ATS to verify
the origin certificates sent to it.
proxy.config.ssl.client.CA.cert.filename and
proxy.config.ssl.client.CA.cert.path.  If you don't care about having ATS
verify the origin certificates, you can leave the
proxy.config.ssl.client.verify.server set to 0.

On Thu, Feb 22, 2018 at 5:46 AM, salil GK <gksa...@gmail.com> wrote:

> I have set client server verification to 'no'
>
> CONFIG proxy.config.ssl.client.verify.server INT 0
>
> and this time things went fie and ATS worked as forward proxy.
> So looks like client verification failure in server side only I guess ?
>
> Thanks
> ~S
>
> On 22 February 2018 at 01:14, Susan Hinrichs <shinr...@oath.com> wrote:
>
>> It looks like in this exchange the client did not send a client
>> certificate.  But the other exchanges in the log file don't have the "
>> ssl3_get_client_certificate:peer did not return a certificate" message.
>> So perhaps one test exchange had the client certificate missing.
>>
>> The server certificate is being selected, so I assume the server
>> certificate message is being sent back to the client.
>>
>> On Wed, Feb 21, 2018 at 1:11 PM, Alan Carroll <solidwallofc...@oath.com>
>> wrote:
>>
>>> This looks like the important part of the logs (you can drop by my desk
>>> for further detail if you want, Susan & Persia). AFAICT this covers an
>>> entire transaction. I checked the start up messages and saw no errors, but
>>> I did not see any mention of 'ca.pem'. Is there some typo in his
>>> configuration? Is the ATS version too old to support client certificate
>>> verification? I'm beginning to suspect that.
>>>
>>> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
>>> {0x7fd7da831740} DEBUG:  (ssl)
>>> [SSLNextProtocolAccept:mainEvent] event 202 netvc 0x5567d9e4aca0
>>> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
>>> {0x7fd7da831740} DEBUG: 
>>> (ssl) IP context is (nil) for [XXX.XXX.XXX.33:34686] ->
>>> [XXX.XXX.XXX.XXX:8445], default context 0x5567d9bcf430
>>> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
>>> {0x7fd7da831740} DEBUG:  (ssl)
>>> ssl_callback_info ssl: 0x5567d9a86d30 where: 16 ret: 1
>>> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
>>> {0x7fd7da831740} DEBUG:  (ssl)
>>> ssl_callback_info ssl: 0x5567d9a86d30 where: 8193 ret: 1
>>> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
>>> {0x7fd7da831740} DEBUG:  (ssl)
>>> set_context_cert ssl=0x5567d9a86d30 server=gmt-dvor-vcsc1.cisco.com
>>> handshake_complete=0
>>> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
>>> {0x7fd7da831740} DEBUG:  (ssl)
>>> ssl_cert_callback found SSL context 0x5567d9bcf430 for requested name '
>>> gmt-dvor-vcsc1.cisco.com'
>>> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
>>> {0x7fd7da831740} DEBUG:  (ssl)
>>> callHooks sslHandshakeHookState=0
>>> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
>>> {0x7fd7da831740} DEBUG:  (ssl)
>>> ssl_callback_info ssl: 0x5567d9a86d30 where: 8193 ret: 1
>>> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
>>> {0x7fd7da831740} DEBUG:  (ssl)
>>> ssl_callback_info ssl: 0x5567d9a86d30 where: 8193 ret: 1
>>> 2018-02-21T10:21:42.661+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
>>> {0x7fd7da831740} DEBUG:  (ssl)
>>> ssl_callback_info ssl: 0x5567d9a86d30 where: 8193 ret: 1
>>> 2018-02-21T10:21:42.681+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
>>> {0x7fd7da831740} DEBUG:  (ssl)
>>> ssl_callback_info ssl: 0x5567d9a86d30 where: 8193 ret: 1
>>> 2018-02-21T10:21:42.681+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
>>> {0x7fd7da831740} DEBUG:  (ssl)
>>> ssl_callback_info ssl: 0x5567d9a86d30 where: 8193 ret: 1
>>> 2018-02-21T10:21:42.681+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
>>> {0x7fd7da831740} DEBUG:  (ssl)
>>> ssl_callback_info ssl: 0x5567d9a86d30 where: 8193 ret: 1
>>> 2018-02-21T10:21:42.681+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
>>> {0x7fd7da831740} DEBUG:  (ssl)
>>> ssl_callback_info ssl: 0x5567d9a86d30 where: 8194 ret: -1
>>> 2018-02-21T10:21:42.681+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
>>> {0x7fd7da831740} DEBUG:  (ssl)
>>> ssl_callback_info ssl: 0x5567d9a86d30 where: 8194 ret: -1
>>> 2018-02-21T10:21:42.681+00:00 gm

Re: Connection rejected for MTLS forward proxy

[Susan Hinrichs]

gmt-dvor-vcsc1 traffic_server[10353]:
> {0x7fd7da831740} DEBUG:  (sslServerHandShakeEvent)> (ssl) SSL::140565060720448:error:140890C7:SSL
> routines:ssl3_get_client_certificate:peer did not return a
> certificate:s3_srvr.c:3413: peer address is XXX.XXX.XXX.33
> 2018-02-21T10:21:42.749+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
> {0x7fd7da831740} DEBUG:  (sslServerHandShakeEvent)> (ssl) SSL handshake error: SSL_ERROR_SSL (1),
> errno=0
> 2018-02-21T10:21:42.749+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
> {0x7fd7da831740} DEBUG:  (sslServerHandShakeEvent)> (ssl) SSLNetVConnection::sslServerHandShakeEvent,
> SSL_ERROR_SSL errno=0
>
> Here's a bit more from process start, which is the only certificate I see
> loaded:
>
> 2018-02-21T08:32:50.209+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
> {0x7fd7da831740} DEBUG:  (ssl)
> importing SNI names from server.pem
> 2018-02-21T08:32:50.209+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
> {0x7fd7da831740} DEBUG:  (ssl)
> mapping 'gmt-dvor-vcsc1.cisco.com' to certificate server.pem
> 2018-02-21T08:32:50.209+00:00 gmt-dvor-vcsc1 traffic_server[10353]:
> {0x7fd7da831740} DEBUG:  (ssl) indexed '
> gmt-dvor-vcsc1.cisco.com' with SSL_CTX 0x5567d9bcf430 [1]
>
>
> On Wed, Feb 21, 2018 at 12:22 PM, Susan Hinrichs <shinr...@oath.com>
> wrote:
>
>> If you are in a test environment where you can share your wireshark pcap
>> file that might also be interesting.
>>
>> On Wed, Feb 21, 2018 at 11:58 AM, Persia Aziz <persia.a...@yahoo.com>
>> wrote:
>>
>>> Do you see this EOF if you have client verification disabled?
>>>
>>> Syeda Persia Aziz
>>> Software Developer
>>> Yahoo! Inc.
>>> Champaign, Illinois
>>>
>>>
>>> On Wednesday, February 21, 2018, 11:48:40 AM CST, Persia Aziz <
>>> persia.a...@yahoo.com> wrote:
>>>
>>>
>>>
>>> Hmm interesting. From  your debug log, looks like ATS wants to read more
>>> data from the buffer which it can not find. Hence, throwing an EOF.
>>>
>>> Syeda Persia Aziz
>>> Software Developer
>>> Yahoo! Inc.
>>> Champaign, Illinois
>>>
>>>
>>> On Wednesday, February 21, 2018, 11:35:11 AM CST, salil GK <
>>> gksa...@gmail.com> wrote:
>>>
>>>
>>> I have assigned these variables also the same values -
>>>
>>> CONFIG proxy.config.ssl.CA.cert.filename STRING ca.pem
>>>
>>> CONFIG proxy.config.ssl.CA.cert.path STRING /directory/where/ca.pem
>>>
>>>
>>> # and
>>>
>>>
>>> CONFIG proxy.config.ssl.client.CA.cert.filename STRING ca.pem
>>>
>>> CONFIG proxy.config.ssl.client.CA.cert.path STRING
>>> /directory/where/ca.pem
>>>
>>> On 21 February 2018 at 22:48, Persia Aziz <persia.a...@yahoo.com> wrote:
>>>
>>> Hi,
>>>
>>> What you want is 'proxy.config.ssl.CA.cert. filename' and 
>>> proxy.config.ssl.CA.cert.
>>> path not the client.CA configs. I know it is a bit confusing. The
>>> client.CA ones are used to verify origin server certificates. Try the
>>> configs and see if that works.
>>>
>>> Docs for the configs:
>>>
>>> records.config — Apache Traffic Server 8.0.0 documentation
>>> <https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html?highlight=proxy%20config%20ssl%20ca%20cert%20filename#proxy.config.ssl.CA.cert.filename>
>>>
>>> records.config — Apache Traffic Server 8.0.0 documentation
>>>
>>>
>>> <https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html?highlight=proxy%20config%20ssl%20ca%20cert%20filename#proxy.config.ssl.CA.cert.filename>
>>>
>>>
>>>
>>> - Sincerely
>>> Syeda Persia Aziz
>>> Software Developer
>>> Yahoo! Inc.
>>> Champaign, Illinois
>>>
>>>
>>> On Wednesday, February 21, 2018, 10:41:32 AM CST, Alan Carroll <
>>> solidwallofc...@oath.com> wrote:
>>>
>>>
>>> I meant more what *units* the handshake_timer is. Looking at the code,
>>> it seems to be in seconds meaning it is unlikely that is the problem (if
>>> the handshake took .5s with a 20s timeout).
>>>
>>> I'd recommend having any configuration value at most once, although I
>>> don't think it would break anything.
>>>
>>> Looking at the code, it appears the client cert verify callback was hit
>>> (SSLUtils.cc:1687) with a failure reported by openSSL. I'd look at debug
>>> messages much earlier, during process start, to see if the certs are
>>> getting loaded correctly.
>>>
>>>
>>>
>>>
>>
>

Re: Connection rejected for MTLS forward proxy

[Susan Hinrichs]

If you are in a test environment where you can share your wireshark pcap
file that might also be interesting.

On Wed, Feb 21, 2018 at 11:58 AM, Persia Aziz  wrote:

> Do you see this EOF if you have client verification disabled?
>
> Syeda Persia Aziz
> Software Developer
> Yahoo! Inc.
> Champaign, Illinois
>
>
> On Wednesday, February 21, 2018, 11:48:40 AM CST, Persia Aziz <
> persia.a...@yahoo.com> wrote:
>
>
>
> Hmm interesting. From  your debug log, looks like ATS wants to read more
> data from the buffer which it can not find. Hence, throwing an EOF.
>
> Syeda Persia Aziz
> Software Developer
> Yahoo! Inc.
> Champaign, Illinois
>
>
> On Wednesday, February 21, 2018, 11:35:11 AM CST, salil GK <
> gksa...@gmail.com> wrote:
>
>
> I have assigned these variables also the same values -
>
> CONFIG proxy.config.ssl.CA.cert.filename STRING ca.pem
>
> CONFIG proxy.config.ssl.CA.cert.path STRING /directory/where/ca.pem
>
>
> # and
>
>
> CONFIG proxy.config.ssl.client.CA.cert.filename STRING ca.pem
>
> CONFIG proxy.config.ssl.client.CA.cert.path STRING /directory/where/ca.pem
>
> On 21 February 2018 at 22:48, Persia Aziz  wrote:
>
> Hi,
>
> What you want is 'proxy.config.ssl.CA.cert. filename' and 
> proxy.config.ssl.CA.cert.
> path not the client.CA configs. I know it is a bit confusing. The
> client.CA ones are used to verify origin server certificates. Try the
> configs and see if that works.
>
> Docs for the configs:
>
> records.config — Apache Traffic Server 8.0.0 documentation
> 
>
> records.config — Apache Traffic Server 8.0.0 documentation
>
>
> 
>
>
>
> - Sincerely
> Syeda Persia Aziz
> Software Developer
> Yahoo! Inc.
> Champaign, Illinois
>
>
> On Wednesday, February 21, 2018, 10:41:32 AM CST, Alan Carroll <
> solidwallofc...@oath.com> wrote:
>
>
> I meant more what *units* the handshake_timer is. Looking at the code, it
> seems to be in seconds meaning it is unlikely that is the problem (if the
> handshake took .5s with a 20s timeout).
>
> I'd recommend having any configuration value at most once, although I
> don't think it would break anything.
>
> Looking at the code, it appears the client cert verify callback was hit
> (SSLUtils.cc:1687) with a failure reported by openSSL. I'd look at debug
> messages much earlier, during process start, to see if the certs are
> getting loaded correctly.
>
>
>
>

Re: Traffic server request

[Susan Hinrichs]

In addition the underlying single box configuration is described in the ATS
documentation https://docs.trafficserver.apache.org/en/latest/


On Tue, Nov 14, 2017 at 7:08 AM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> Hi Vasanth-
>   Please take a look at Apache Traffic Control. It provides configuration
> and monitoring of traffic server based CDNs.
>
> https://trafficcontrol.apache.org/
>
> —Eric
>
> On Nov 14, 2017, at 7:46 AM, Vasanth Mathivanan <
> vasant...@evolutiondigital.com> wrote:
>
> Hi,
>
> I need  Document for CDN Config in ATS
>
>
> Thanks & Regards
>
> Vasanth
>
> Sent from Mail  for
> Windows 10
>
>
>

Please add me

[SUSAN HINRICHS]

shinr...@ieee.org

Re: [VOTE] Release Apache Traffic Server 7.1.0 (RC1)

[Susan Hinrichs]

+1 Running for 24 hours on a production box without problems.

On Thursday, July 20, 2017, 1:19:26 AM CDT, Phillip Moore  
wrote:

+1

 Have running on internal staging and production traffic and it is working
fine.  I had no build troubles on SL6.9.

--pdm

Re: [VOTE] Release Apache Traffic Server 7.1.0 (RC0)

[Susan Hinrichs]

+1    I have run this on two machines over the weekend successfully.

On Thursday, July 13, 2017, 9:44:34 PM CDT, Leif Hedstrom  
wrote:

I've prepared a release for 7.1.0 (RC0) which is the next major version of 
Apache Traffic Server. As per our new release schedule and process, v7.1.x is 
an Long-Term Support (LTS) release.  This is detailed in our Release Management 
document:

    https://cwiki.apache.org/confluence/display/TS/Release+Management


Release notes for 7.1.0:

    https://github.com/apache/trafficserver/milestone/2?closed=1


This release of v7.1.0 is backwards compatible with v7.0.0, for some details as 
to what’s in v.7.1.x see

    https://cwiki.apache.org/confluence/display/TS/What%27s+New+in+v7.1.x


Information about upgrading to this release from previous major versions is 
available at:

    https://cwiki.apache.org/confluence/display/TS/Upgrading+to+v7.0

The artifacts are available for download at:

    http://people.apache.org/~zwoop/rel-candidates/


Checksums:

    MD5: e91212248af3ef6da9519025fc8b39a5 *trafficserver-7.1.0-rc0.tar.bz2
    SHA1: d98907215a2ccae59882d9c2d65543505268ee18 
*trafficserver-7.1.0-rc0.tar.bz2


This corresponds to git:

    Hash: bbfd439ee6cd7f5cc3abf8daafe447b61df91481
    Tag: 7.1.0-rc0


Which can be verified with the following command:

    $ git tag -v 7.1.0-rc0


All code signing keys are available here:

    https://dist.apache.org/repos/dist/dev/trafficserver/KEYS

Make sure you refresh from a key server to get all relevant signatures. This 
vote is open until July 20th..

Cheers,

— Leif

Re: Bandwidth on certain destination (squid delay pool)

[Susan Hinrichs]

But a TC based solution might work for Faisal.  In the short term.

On 4/7/2016 1:23 PM, Sudheer Vinukonda wrote:

No, that was based on TC;

The plugin I wrote doesn't depend on TC and is all handled within ATS.


On Thursday, April 7, 2016 11:08 AM, Susan Hinrichs 
<shinr...@network-geographics.com> wrote:



Sudheer, is this similar to the patch you helped Faysal with? 
https://issues.apache.org/jira/browse/TS-2643



On 4/7/2016 10:32 AM, Sudheer Vinukonda wrote:

Not to the best of my knowledge.

However, you can write a plugin to do that (in fact, I've such a 
plugin that I'm using internally in our Origin Protection layer). It 
might be a while before I can open source the plugin though.


Thanks,

Sudheer


On Thursday, April 7, 2016 6:05 AM, Muhammad Faisal 
<faisalu...@yahoo.com> <mailto:faisalu...@yahoo.com> wrote:



Hi,
Is there any method we can limit the downloads/bandiwdth on certain 
destinations based on origin or regex in ATS? .

PS: A feature call delay pools in squid allows to throttle bandwidth.
--
Regards,
Faisal.

Re: Bandwidth on certain destination (squid delay pool)

[Susan Hinrichs]

Sudheer, is this similar to the patch you helped Faysal with? 
https://issues.apache.org/jira/browse/TS-2643



On 4/7/2016 10:32 AM, Sudheer Vinukonda wrote:

Not to the best of my knowledge.

However, you can write a plugin to do that (in fact, I've such a 
plugin that I'm using internally in our Origin Protection layer). It 
might be a while before I can open source the plugin though.


Thanks,

Sudheer


On Thursday, April 7, 2016 6:05 AM, Muhammad Faisal 
 wrote:



Hi,
Is there any method we can limit the downloads/bandiwdth on certain 
destinations based on origin or regex in ATS? .

PS: A feature call delay pools in squid allows to throttle bandwidth.
--
Regards,
Faisal.

CFP Apachecon NA 2016 deadline is Friday

[Susan Hinrichs]

The deadline for talk proposals for Apachecon NA is this Friday.

http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp

Please consider submitting something about your current work, planned 
work, experiences, etc. using ATS and/or other Apache open source 
projects.   We need more networking/systems oriented presentations.


The ATS summit will also be in Vancover before Apachecon, so you can 
optimize your travel time and budget with two events.

Re: transparent proxy (inline on a linux bridge) not work

[Susan Hinrichs]

Are you starting traffic manager as a privileged user?  Sounds like a 
permission error.


On 8/10/2015 9:37 PM, Wayne Zhang wrote:

Hi.

I followed the steps strictly from the official documents here :
http://trafficserver.readthedocs.org/en/latest/admin/transparent-proxy/bridge.en.html#inline-on-a-linux-bridge

the source code version is 5.3.1.
my linux kernel is 3.8.0-44, and I checked that the xt_TPROXY model 
was loaded after executing iptables command.

config.log shows getting the right value 19.

then the Linux ethernet bridge works well, *every app on the client PC 
can access the internet but the browser visiting http websites always 
gets timeout (https is ok)*.
the 3 processes traffic_cop, traffic_manager and traffic_server can be 
seen using ps aux.

there is no access log file squid.log in the log path.
and the Wireshark on the PC using as bridge can not find any 
interfaces in this situation.


I tried to change the value of proxy.config.http.server_ports from the 
default 8080 to 8080:ipv4:tr-full, then I got error Unable to set 
transparent socket option operation not permitted, and only one 
process traffic_cop remained.


How to fix this ? Thanks in advance.

Re: [VOTE] Release Apache Traffic Server 5.3.1 (RC0)

[Susan Hinrichs]

+1 also tested on CentOS 6.5.

On 7/3/2015 11:03 AM, Phil Sorber wrote:

+1 Tested on CentOS 6.5

On Thu, Jul 2, 2015 at 4:09 PM Bryan Call bc...@apache.org 
mailto:bc...@apache.org wrote:


+1

Tested on Fedora 22.  Signatures and regression passed.

-Bryan


 On Jun 29, 2015, at 9:56 PM, Phil Sorber sor...@apache.org
mailto:sor...@apache.org wrote:

 Hello All,

 I've prepared a release for v5.3.1 (RC0) which is the latest
stable release
 in the 5.3.x series. This is the second release in our Long Term
Support
 (LTS) version as detailed in our Release Management document:

 https://cwiki.apache.org/confluence/display/TS/Release+Management

 Changes since 5.3.0:



https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12327092projectId=12310963

 Of special note are two fixes for CVE-2015-3249 that effect the
HTTP/2
 experimental feature in Apache Traffic Server 5.3.0. They are
both DOS
 attacks and can be avoided by simply disabling HTTP/2 or upgrading.

 A summary of the new features in 5.3.x are here:


https://cwiki.apache.org/confluence/display/TS/What%27s+new+in+v5.3.x

 Information about upgrading to this release from previous ones
is available
 at:

 https://cwiki.apache.org/confluence/display/TS/Upgrading+to+v5.0

 The cache in this release is compatible with the previous 5.x
and 4.x
 releases.

 The artifacts are available for download at:


http://people.apache.org/~sorber/releases/trafficserver/5.3.1-rc0/
http://people.apache.org/%7Esorber/releases/trafficserver/5.3.1-rc0/

 MD5: 9c0e2450b1dd1bbdd63ebcc344b5a813
 SHA1: 771d3fafac6b8e144376fb16398f03b79f39912f

 This corresponds to git:

 Hash: 38b4113f5e9e6aa6c659c4f5e0eaf7db2f1ff67e
 Tag: 5.3.1-rc0

 Which can be verified with the following:

 git tag -v 5.3.1-rc0

 My code signing key is available here:

 http://people.apache.org/~sorber/gpg-code-signing-key.asc
http://people.apache.org/%7Esorber/gpg-code-signing-key.asc

 Make sure you refresh from a key server to get all relevant
signatures.

 The vote is open until Jul 2nd 2015. This is shorter than normal
because it
 is a bug fix/security release and the holiday weekend.

 Thanks All!

Proposed change in default cipher_suite list for ATS 6.0

[Susan Hinrichs]

We are planning on changing the default cipher_suite list as we move to 
ATS 6.0.  The jira outlines the discussion on this issue 
https://issues.apache.org/jira/browse/TS-3136


Here is the last entry of the jira with the proposal and rationale.

Ran some tests on a production box in Y!  Based on those results, I 
suggest the following cipher string.


ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA 



The upshot is that we remove RC4, add new ciphers, and rearrange the 
list to give preference to cipher attributes in the following order: 
PFS, then GCM, then stronger SHA, then stronger AES.  3DES is at the end 
to scoop up the remainders.


We tested in the Y! environment which tends to have a wide variety of 
clients.  Removing RC4 did not seem to significantly impact handshake 
success rate.  CBC algorithms are also concerning, but if we care about 
out-of-the-box experience it looks like the CBC algorithms need to stick 
around for a while longer.


Here are details of the test

With Y! original cipher string
0.0102% ssl_error_ssl

The number of DES-CBC3-SHA sessions was negligible (45).  The Y! initial 
configuration has one RC4 algorithm listed kind of early, so the RC4 
percentage was around 30% as [~davet] noted in an earlier comment.


With proposed default cipher string running for an hour
0.009% ssl_error_ssl

The percentage of DES-CBC3-SHA sessions grew to 0.9% of sessions. In my 
experiment, it was impossible to isolate the CPU impact of this change.  
To test a new cipher without updating all the machines in the production 
pod, I removed the test box from the SSL session sharing communication.  
The test box experienced around a 30% increase in CPU utilization, but I 
think that can be mostly attributed to increased session negotiation 
since it did not know about the sessions negotiated by other machines in 
the pod.


We did one experiment with the RC4 ciphers added after DES-CBC3 as 
another measure of how many clients are only willing to do RC4. After 
about an hour, 2 RC4 sessions were started.


510932 = Total Successful Handshakes

Percentage of various cipher's negotiated

# Start with PFS/GCM ciphers.  Give slight preference to AES256 over 
AES128, and prefer stronger SHA

0%  ECDHE-ECDSA-AES256-GCM-SHA384:
4.2%   ECDHE-RSA-AES256-GCM-SHA384:
0%  ECDHE-ECDSA-AES128-GCM-SHA256:
30.6% ECDHE-RSA-AES128-GCM-SHA256:
# DHE still gives of PFS but at increased computation cost
0%  DHE-RSA-AES256-GCM-SHA384:
0%  DHE-DSS-AES256-GCM-SHA384:
0%  DHE-RSA-AES128-GCM-SHA256:
0%  DHE-DSS-AES128-GCM-SHA256:
# CBC versions of the PFS ciphers
0%  ECDHE-ECDSA-AES256-SHA384:
30.6% ECDHE-RSA-AES256-SHA384:
0%  ECDHE-ECDSA-AES256-SHA:
27.7% ECDHE-RSA-AES256-SHA:
0%  ECDHE-ECDSA-AES128-SHA256:
0%  ECDHE-RSA-AES128-SHA256:
0%  ECDHE-ECDSA-AES128-SHA:
0.14% ECDHE-RSA-AES128-SHA:
0%  DHE-RSA-AES256-SHA256:
0%  DHE-DSS-AES256-SHA256:
0%  DHE-RSA-AES128-SHA256:
0%  DHE-DSS-AES128-SHA256:
0%  DHE-RSA-AES256-SHA:
0%  DHE-DSS-AES256-SHA:
0%  DHE-RSA-AES128-SHA:
0%  DHE-DSS-AES128-SHA:
# No PFS, GCM
0.3%   AES256-GCM-SHA384:
0%  AES128-GCM-SHA256:
# No PFS, CBC
0.2%   AES256-SHA256:
0%  AES128-SHA256:
4.8%   AES256-SHA:
0.5%   AES128-SHA:
# 3DES as a last resort
0.9%   DES-CBC3-SHA

Re: 5.3.0: TLS completly broken (reverse-proxy)

[Susan Hinrichs]

Hmm.  I just ran ssllabs against 
https://docs.trafficserver.apache.org/en/latest/ which is running 5.3.x 
(which I think is the same as 5.3.0).  All was happy.  Will need to look 
more closely at your records.config.   Good to know that running sslscan 
locally also produces the problem.  Should get this figured out before 
you need to move up to 5.3.x.


On 5/26/2015 2:40 PM, Reindl Harald wrote:



Am 26.05.2015 um 21:32 schrieb Susan Hinrichs:

Hi Riendl,

I'll have to try to reproduce from outside the office.

If I understand you correctly, you can access the server behind ATS ok.
Then you do the ssllabs scan (which fails badly).  Then your browser can
no longer access the server.

Definitely sounds like badness.


forget the server behind ATS, there are multiple and they are innocent

* ATS 5.3.0 seems to work fine in the browser
* ssllabs says no connection
* the same host no longer responds in the browser
* other reverse proxy hosts appears to work still fine
* ssllabs them, they are also gone
* it's not only ssllabs, local sslscan to ATS kills it also
* the problem is no shared ciphers

something seems to go terrible wrong with multiple TLS hosts, some of 
them configured for just TLS-offloading, some of them also use TLS to 
the origin (caused by a backend CMS not handle external offloading 
properly) and a mix of our wildcard certificate and host-specific ones


happily i recognized that very soon and built 5.2.1 for Fedora 21 
(x86_64) wich was also running with F20 on that machine


no time to dig that deeper because i am at dist-upgrades for around 30 
servers and ATS was the only problem until now, happily 5.2.1 still 
works fine



On 5/26/2015 2:22 PM, Reindl Harald wrote:



Am 26.05.2015 um 21:04 schrieb Dave Thompson:

Hi Riendl,

More details regarding host might help, though if the issue is related
to having an external scanner contact an internal ATS, you can test 
TCP

connectivity with just a 'telnet hostname port'.


TLS is fucked up, nobody talks about a internal host


To test SSL handshake, you might alternatively try:
openssl s_client -connect login.yahoo.com:443  /dev/null

If you're trying an internal scan to something that ssllabs.com can't
access, you might be interested in checking out:
yo/checkmyssl


uhm that is and was a production server runnigng as reverse proxy and
reachable from ssllabs - the point is that *after* ssllabs try to scan
the host the page is dead and firefox complaints in no shared ciphers

please read again my post!

for me that's now done by downgrade to 5.2.1 and all is fine as before
with nothing else changed

On Tuesday, May 26, 2015 1:34 PM, Reindl Harald 
h.rei...@thelounge.net

wrote:


i recently did a dist-upgrade to Fedora 21 and at that time decided to
upgrade ATS to 5.3.0 since load-tests without encryption where fine

well, https://www.ssllabs.com/ssltest/
https://www.ssllabs.com/ssltest/says no connection, after that
Firefox previously displayed the page said no shared ciphers at
reload, local sslcsan is more than strange - in other words: as soon
as you start to scan the server for ssl ciphers something goes 
terrible

wrong

it happens that another SNI host still works, until you try to scan
it too

downgrade to 5.2.1 and all is fine again
P.S.: the download page should not only list a .0 release
__

without changing the environment these different results for sslscan
host:443 should be impossible

   Preferred Server Cipher(s):
 SSLv2  0 bits(NONE)
 SSLv3  0 bits(NONE)
 TLSv1  0 bits(NONE)
 TLS11  0 bits(NONE)
 TLS12  0 bits(NONE)

   Preferred Server Cipher(s):
 SSLv2  0 bits(NONE)
 SSLv3  0 bits(NONE)
 TLSv1  0 bits(NONE)
 TLS11  0 bits(NONE)
 TLS12  128 bits  ECDHE-RSA-AES128-GCM-SHA256
__

5.2.1:

   Preferred Server Cipher(s):
 SSLv2  0 bits(NONE)
 SSLv3  0 bits(NONE)
 TLSv1  128 bits  ECDHE-RSA-AES128-SHA
 TLS11  128 bits  ECDHE-RSA-AES128-SHA
 TLS12  128 bits  ECDHE-RSA-AES128-GCM-SHA256
__

records.config

## 



# System Variables
   #
## 



CONFIG proxy.config.proxy_name STRING proxy.thelounge.net
CONFIG proxy.config.config_dir STRING /etc/trafficserver
CONFIG proxy.config.proxy_binary_opts STRING -M
CONFIG proxy.config.temp_dir STRING /tmp
CONFIG proxy.config.alarm_email STRING ats
CONFIG proxy.config.syslog_facility STRING LOG_DAEMON
CONFIG proxy.config.output.logfile STRING traffic.out
CONFIG proxy.config.snapshot_dir STRING snapshots
CONFIG proxy.config.system.mmap_max INT 2097152

## 



# Main threads configuration (worker threads). Also see configurations

Re: memory leak related to ssl termination

[Susan Hinrichs]

We are tracking a memory leak issue on ssl_multicert.config reload. But 
I'm not aware of substantial memory leak for SSL traffic passing through.


Are you running in forward proxy or reverse proxy?  Are you running in 
transparent mode?


Operating with SSL will use more memory than straight HTTP over TCP.  Is 
it possible that your steady state memory usage has increased over the 
TCP case?


On 5/17/2015 9:01 AM, Esmq wrote:

hi,all

i have encounter seriously memory leak problem related to ats.


after testing for several times, it is confirmed that the problem is 
caused by *ssl termination.*


the following testing i haved done:
1) runing ats on several servers with same hardware/software 
configuration.
2) when configure some ats for ssl termination, these servers have 
memory leak...

3) when disabled ssl termination, the problem gone.
4) the ssl requests rate is about 100-200 requests/second
5)*ats that enabled ssl termination increased memory usage continually 
(increase 10MB in 1 minutes)*

6) the problem not fixed in v5.3.0


my system env and configuration is :

###
runing ats on debian7 64bit system(3.2.0-4-amd64), compile the ats 
with following paramters:


./configure --prefix=/usr/local/trafficserver-5.3.0 --enable-spdy 
--with-user=trafficserver --with-group=trafficserver 
--sysconfdir=/home/trafficserver/etc --enable-experimental-plugins 
--enable-reclaimable-freelist --enable-hwloc


###
and the ssl related configuration is :

CONFIG proxy.config.http.server_ports STRING 80:proto=spdy;http 
443:proto=spdy;http:ssl

CONFIG proxy.config.ssl.number.threads INT 0
CONFIG proxy.config.ssl.SSLv2 INT 0
CONFIG proxy.config.ssl.SSLv3 INT 1
CONFIG proxy.config.ssl.TLSv1 INT 1
CONFIG proxy.config.ssl.server.cipher_suite STRING 
RC4-SHA:AES128-SHA:DES-CBC3-SHA:AES256-SHA:ALL:!aNULL:!EXP:!LOW:!MD5:!SSLV2:!NULL

CONFIG proxy.config.ssl.server.honor_cipher_order INT 1
CONFIG proxy.config.ssl.compression INT 0
CONFIG proxy.config.ssl.client.certification_level INT 0
CONFIG proxy.config.ssl.server.cert_chain.filename STRING NULL
CONFIG proxy.config.ssl.server.cert.path STRING /home/trafficserver/etc
CONFIG proxy.config.ssl.server.private_key.path STRING 
/home/trafficserver/etc

CONFIG proxy.config.ssl.CA.cert.filename STRING NULL
CONFIG proxy.config.ssl.CA.cert.path STRING /home/trafficserver/etc
CONFIG proxy.config.ssl.client.verify.server INT 0
CONFIG proxy.config.ssl.client.cert.filename STRING NULL
CONFIG proxy.config.ssl.client.cert.path STRING /home/trafficserver/etc
CONFIG proxy.config.ssl.client.private_key.filename STRING NULL
CONFIG proxy.config.ssl.client.private_key.path STRING 
/home/trafficserver/etc

CONFIG proxy.config.ssl.client.CA.cert.filename STRING NULL
CONFIG proxy.config.ssl.client.CA.cert.path STRING /home/trafficserver/etc
CONFIG proxy.config.ssl.hsts_max_age INT -1
CONFIG proxy.config.ssl.hsts_include_subdomains INT 0

###
ssl_multicert.config:
ssl_cert_name=ssl/mdc.test.com.crt ssl_key_name=ssl/mdc.test.com.key
ssl_cert_name=ssl/daily.test.com.crt ssl_key_name=ssl/daily.test.com.key
dest_ip=* ssl_cert_name=ssl/sslbbs.example.com.ee.crt 
ssl_key_name=ssl/sslbbs.example.com.nopass.key


#

is there any configuration that can relieve the memory leak ?

does anyone have the suggestion？

Re: SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

[Susan Hinrichs]

I just tried ab against my dev master build without problems.  I have 
SSLv3 disabled.  It ended up negotiating tlsv1.2.  I saw one error about 
protocol mismatch while I was playing around.


I also ran the the ssllabs tests against docs.trafficserver.apache.org 
which is fronted by an ATS server. The only client handshake error it 
reported was IE6 on winXP (since SSLv3 is disabled).


Can you give details about your configuration?  We must be doing 
something different.


On 4/16/2015 6:31 AM, Reindl Harald wrote:



Am 16.04.2015 um 13:22 schrieb Susan Hinrichs:

Are you seeing actual failed connections? Or is ATS just logging more
intermediate error cases than httpd?


it is just impossible to use ab against a ATS, see difference below 
and when you run https://www.ssllabs.com/ssltest/ against both sites 
you see SSL2/SSL3 disabled on both


that pretty sure affects also other older clients not only ab for no 
good reasons

__

[harry@rh:~]$ ab -n 1 https://www.thelounge.net/
This is ApacheBench, Version 2.3 $Revision: 1638069 $
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.thelounge.net (be patient)...SSL handshake failed (1).
140536880785376:error:14077410:SSL 
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake 
failure:s23_clnt.c:770:

..done
__

[harry@rh:~]$ ab -n 1 https://secure.thelounge.net/
This is ApacheBench, Version 2.3 $Revision: 1638069 $
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking secure.thelounge.net (be patient).done

Server Software:
Server Hostname:secure.thelounge.net
Server Port:443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,4096,128
__


On 4/16/2015 6:13 AM, Reindl Harald wrote:


Am 16.04.2015 um 13:08 schrieb Neddy, NH. Nam:
Yeah, it's been long time: 
https://issues.apache.org/jira/browse/TS-2402


SSL v3 is disabled is a completly different story than breaking
client handshakes, as said *all* our services have SSL3 disabled and
you can benchmark a httpd-server without any issues with ab


On Thu, Apr 16, 2015 at 4:57 PM, Reindl Harald
h.rei...@thelounge.net wrote:

why is it still a issue doing a benchmark to a ATS server with ab
-c 100 -n
2 https://traffic-server-site/; while the same works just fine
when the
server is a normal httpd with SSLv3 also disabled?

140343245031392:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:770:
SSL handshake failed (1).
140343245031392:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:770:
SSL handshake failed (1).
140343245031392:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:770:
SSL handshake failed (1).
140343245031392:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:770:
SSL handshake failed (1).
140343245031392:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:770:
SSL handshake failed (1).
140343245031392:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:770

Re: SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

[Susan Hinrichs]

Yes,  I see the same failures when I run ab against your 
https://www.thelounge.net/ site.  I'll get a 5.2.x environment setup, 
and try setting dhparams.  Those look like the major differences in our 
environments.


On 4/16/2015 7:11 AM, Reindl Harald wrote:


Am 16.04.2015 um 13:50 schrieb Susan Hinrichs:

I just tried ab against my dev master build without problems.  I have
SSLv3 disabled.  It ended up negotiating tlsv1.2.  I saw one error about
protocol mismatch while I was playing around.


interesting


I also ran the the ssllabs tests against docs.trafficserver.apache.org
which is fronted by an ATS server. The only client handshake error it
reported was IE6 on winXP (since SSLv3 is disabled).


ssllabs is just fine, for now only ab from the httpd-tools is broken 
as well i face random handshake errors from a httpd running as proxy 
in front of our ATS on a client side (difficult reasons for that 
chaining)



Can you give details about your configuration?  We must be doing
something different.


* Fedora 20 x86_64
* ATS 5.2.1
* openssl-1.0.1e-42.fc20

the certificate is a RSA4096 SHA256 wildcard, the same as on 
https://secure.thelounge.net/ which is running httpd while 
https://www.thelounge.net/ is running ATS in front


cat records.config  | grep ssl
CONFIG proxy.config.http.server_ports STRING 80 443:ssl
CONFIG proxy.config.ssl.SSLv2 INT 0
CONFIG proxy.config.ssl.SSLv3 INT 0
CONFIG proxy.config.ssl.TLSv1 INT 1
CONFIG proxy.config.ssl.TLSv1_1 INT 1
CONFIG proxy.config.ssl.TLSv1_2 INT 1
CONFIG proxy.config.ssl.client.SSLv2 INT 1
CONFIG proxy.config.ssl.client.SSLv3 INT 1
CONFIG proxy.config.ssl.client.TLSv1 INT 1
CONFIG proxy.config.ssl.client.TLSv1_1 INT 1
CONFIG proxy.config.ssl.client.TLSv1_2 INT 1
CONFIG proxy.config.ssl.client.certification_level INT 0
CONFIG proxy.config.ssl.server.multicert.filename STRING 
ssl_multicert.config

CONFIG proxy.config.ssl.server.cert.path STRING /etc/trafficserver/ssl/
CONFIG proxy.config.ssl.server.private_key.path STRING 
/etc/trafficserver/ssl/

CONFIG proxy.config.ssl.CA.cert.path STRING /etc/trafficserver/ssl/
CONFIG proxy.config.ssl.server.cipher_suite STRING 
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-CAMELLIA256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:CAMELLIA128-SHA:CAMELLIA256-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA:!LOW:!MEDIUM

CONFIG proxy.config.ssl.server.honor_cipher_order INT 1
CONFIG proxy.config.ssl.server.dhparams_file STRING 
/etc/trafficserver/ssl/dhparams.pem



On 4/16/2015 6:31 AM, Reindl Harald wrote:


Am 16.04.2015 um 13:22 schrieb Susan Hinrichs:

Are you seeing actual failed connections? Or is ATS just logging more
intermediate error cases than httpd?


it is just impossible to use ab against a ATS, see difference below
and when you run https://www.ssllabs.com/ssltest/ against both sites
you see SSL2/SSL3 disabled on both

that pretty sure affects also other older clients not only ab for no
good reasons
__

[harry@rh:~]$ ab -n 1 https://www.thelounge.net/
This is ApacheBench, Version 2.3 $Revision: 1638069 $
Copyright 1996 Adam Twiss, Zeus Technology Ltd, 
http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.thelounge.net (be patient)...SSL handshake failed (1).
140536880785376:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake
failure:s23_clnt.c:770:
..done
__

[harry@rh:~]$ ab -n 1 https://secure.thelounge.net/
This is ApacheBench, Version 2.3 $Revision: 1638069 $
Copyright 1996 Adam Twiss, Zeus Technology Ltd, 
http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking secure.thelounge.net (be patient).done

Server Software:
Server Hostname:secure.thelounge.net
Server Port:443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,4096,128
__


On 4/16/2015 6:13 AM, Reindl Harald wrote:


Am 16.04.2015 um 13:08 schrieb Neddy, NH. Nam:

Yeah, it's been long time:
https://issues.apache.org/jira/browse/TS-2402


SSL v3 is disabled is a completly different story than breaking
client handshakes, as said *all* our services have SSL3 disabled and
you can benchmark a httpd-server without any issues with ab


On Thu, Apr 16, 2015 at 4:57 PM, Reindl Harald
h.rei...@thelounge.net wrote:

why is it still a issue doing a benchmark to a ATS server with ab
-c 100 -n
2 https://traffic-server-site/; while the same works just fine
when the
server is a normal httpd with SSLv3 also disabled?

140343245031392:error:14077410:SSL

Re: SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

[Susan Hinrichs]

Are you seeing actual failed connections?  Or is ATS just logging more 
intermediate error cases than httpd?


On 4/16/2015 6:13 AM, Reindl Harald wrote:



Am 16.04.2015 um 13:08 schrieb Neddy, NH. Nam:

Yeah, it's been long time: https://issues.apache.org/jira/browse/TS-2402


SSL v3 is disabled is a completly different story than breaking 
client handshakes, as said *all* our services have SSL3 disabled and 
you can benchmark a httpd-server without any issues with ab


On Thu, Apr 16, 2015 at 4:57 PM, Reindl Harald 
h.rei...@thelounge.net wrote:
why is it still a issue doing a benchmark to a ATS server with ab 
-c 100 -n
2 https://traffic-server-site/; while the same works just fine 
when the

server is a normal httpd with SSLv3 also disabled?

140343245031392:error:14077410:SSL 
routines:SSL23_GET_SERVER_HELLO:sslv3

alert handshake failure:s23_clnt.c:770:
SSL handshake failed (1).
140343245031392:error:14077410:SSL 
routines:SSL23_GET_SERVER_HELLO:sslv3

alert handshake failure:s23_clnt.c:770:
SSL handshake failed (1).
140343245031392:error:14077410:SSL 
routines:SSL23_GET_SERVER_HELLO:sslv3

alert handshake failure:s23_clnt.c:770:
SSL handshake failed (1).
140343245031392:error:14077410:SSL 
routines:SSL23_GET_SERVER_HELLO:sslv3

alert handshake failure:s23_clnt.c:770:
SSL handshake failed (1).
140343245031392:error:14077410:SSL 
routines:SSL23_GET_SERVER_HELLO:sslv3

alert handshake failure:s23_clnt.c:770:
SSL handshake failed (1).
140343245031392:error:14077410:SSL 
routines:SSL23_GET_SERVER_HELLO:sslv3

alert handshake failure:s23_clnt.c:770

Re: SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

[Susan Hinrichs]

On 4/16/2015 7:11 AM, Reindl Harald wrote:




Can you give details about your configuration?  We must be doing
something different.


* Fedora 20 x86_64
* ATS 5.2.1
* openssl-1.0.1e-42.fc20

the certificate is a RSA4096 SHA256 wildcard, the same as on 
https://secure.thelounge.net/ which is running httpd while 
https://www.thelounge.net/ is running ATS in front


I've tried replicating your environment better to no avail.  I'm I 
reading your statement above correctly that there is a httpd proxy in 
between the client and ATS?


Do previous versions of ATS work for you?



cat records.config  | grep ssl
CONFIG proxy.config.http.server_ports STRING 80 443:ssl
CONFIG proxy.config.ssl.SSLv2 INT 0
CONFIG proxy.config.ssl.SSLv3 INT 0
CONFIG proxy.config.ssl.TLSv1 INT 1
CONFIG proxy.config.ssl.TLSv1_1 INT 1
CONFIG proxy.config.ssl.TLSv1_2 INT 1
CONFIG proxy.config.ssl.client.SSLv2 INT 1
CONFIG proxy.config.ssl.client.SSLv3 INT 1
CONFIG proxy.config.ssl.client.TLSv1 INT 1
CONFIG proxy.config.ssl.client.TLSv1_1 INT 1
CONFIG proxy.config.ssl.client.TLSv1_2 INT 1
CONFIG proxy.config.ssl.client.certification_level INT 0
CONFIG proxy.config.ssl.server.multicert.filename STRING 
ssl_multicert.config

CONFIG proxy.config.ssl.server.cert.path STRING /etc/trafficserver/ssl/
CONFIG proxy.config.ssl.server.private_key.path STRING 
/etc/trafficserver/ssl/

CONFIG proxy.config.ssl.CA.cert.path STRING /etc/trafficserver/ssl/
CONFIG proxy.config.ssl.server.cipher_suite STRING 
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-CAMELLIA256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:CAMELLIA128-SHA:CAMELLIA256-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA:!LOW:!MEDIUM

CONFIG proxy.config.ssl.server.honor_cipher_order INT 1
CONFIG proxy.config.ssl.server.dhparams_file STRING 
/etc/trafficserver/ssl/dhparams.pem



On 4/16/2015 6:31 AM, Reindl Harald wrote:


Am 16.04.2015 um 13:22 schrieb Susan Hinrichs:

Are you seeing actual failed connections? Or is ATS just logging more
intermediate error cases than httpd?


it is just impossible to use ab against a ATS, see difference below
and when you run https://www.ssllabs.com/ssltest/ against both sites
you see SSL2/SSL3 disabled on both

that pretty sure affects also other older clients not only ab for no
good reasons
__

[harry@rh:~]$ ab -n 1 https://www.thelounge.net/
This is ApacheBench, Version 2.3 $Revision: 1638069 $
Copyright 1996 Adam Twiss, Zeus Technology Ltd, 
http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.thelounge.net (be patient)...SSL handshake failed (1).
140536880785376:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake
failure:s23_clnt.c:770:
..done
__

[harry@rh:~]$ ab -n 1 https://secure.thelounge.net/
This is ApacheBench, Version 2.3 $Revision: 1638069 $
Copyright 1996 Adam Twiss, Zeus Technology Ltd, 
http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking secure.thelounge.net (be patient).done

Server Software:
Server Hostname:secure.thelounge.net
Server Port:443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,4096,128
__


On 4/16/2015 6:13 AM, Reindl Harald wrote:


Am 16.04.2015 um 13:08 schrieb Neddy, NH. Nam:

Yeah, it's been long time:
https://issues.apache.org/jira/browse/TS-2402


SSL v3 is disabled is a completly different story than breaking
client handshakes, as said *all* our services have SSL3 disabled and
you can benchmark a httpd-server without any issues with ab


On Thu, Apr 16, 2015 at 4:57 PM, Reindl Harald
h.rei...@thelounge.net wrote:

why is it still a issue doing a benchmark to a ATS server with ab
-c 100 -n
2 https://traffic-server-site/; while the same works just fine
when the
server is a normal httpd with SSLv3 also disabled?

140343245031392:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:770:
SSL handshake failed (1).
140343245031392:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:770:
SSL handshake failed (1).
140343245031392:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:770:
SSL handshake failed (1).
140343245031392:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:770:
SSL handshake failed (1).
140343245031392:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:770:
SSL handshake failed (1).
140343245031392:error

Re: SSL results in segmentation fault

[Susan Hinrichs]

Matt,

Is there a basic stack trace in traffic.out?   What is your SSL 
configuration?  Do you have certs set up in ssl_multicert.config? Or are 
you doing a blind tunnel on the SSL traffic?


Susan

On 9/30/2014 2:14 AM, Matthieu Bienvenüe wrote:

Hello !

I'm configuring ATS as a reverse proxy and I need SSL support.

ATS runs on OpenVZ on Debian. It's the version 5.0.1 installed from 
backport packages.


ATS works fine, SSL too. But after a while SSL makes ATS crash.

In manager.log I found that there is a segmentation fault:

[Sep 29 16:08:33.020] Manager {0xb6fb76d0} ERROR: 
[LocalManager::pollMgmtProcessServer] Server Process terminated due to 
Sig 11: Segmentation fault
[Sep 29 16:08:33.021] Manager {0xb6fb76d0} ERROR: 
[Alarms::signalAlarm] Server Process was reset
[Sep 29 16:08:34.041] Manager {0xb6fb76d0} NOTE: 
[LocalManager::startProxy] Launching ts process
[Sep 29 16:08:34.049] Manager {0xb6fb76d0} NOTE: 
[LocalManager::pollMgmtProcessServer] New process connecting fd '16'
[Sep 29 16:08:34.049] Manager {0xb6fb76d0} NOTE: [Alarms::signalAlarm] 
Server Process born


Here is a dump of the syslog when crashing:

Sep 30 07:05:09 ats traffic_manager[5471]: {0xb704d6d0} FATAL: 
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Sep 30 07:05:09 ats traffic_manager[5471]: {0xb704d6d0} ERROR: 
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Sep 30 07:05:09 ats traffic_manager[5471]: {0xb704d6d0} ERROR: (last 
system error 32: Broken pipe)
Sep 30 07:05:09 ats traffic_cop[23694]: cop received child status 
signal [5471 256]
Sep 30 07:05:09 ats traffic_cop[23694]: traffic_manager not running, 
making sure traffic_server is dead

Sep 30 07:05:09 ats traffic_cop[23694]: spawning traffic_manager
Sep 30 07:05:09 ats traffic_manager[6938]: NOTE: --- Manager Starting ---
Sep 30 07:05:09 ats traffic_manager[6938]: NOTE: Manager Version: 
Apache Traffic Server - traffic_manager - 5.0.1 - (build # 7259 on Aug 
25 2014 at 09:26:11)
Sep 30 07:05:09 ats traffic_manager[6938]: NOTE: Unable to set 
RLIMIT_NOFILE(7):cur(1475961),max(1475961)
Sep 30 07:05:09 ats traffic_manager[6938]: NOTE: 
RLIMIT_NOFILE(7):cur(3),max(3)
Sep 30 07:05:09 ats traffic_manager[6938]: ERROR == [runAsUser] 
Error: Failed to restore capabilities after switch to user trafficserver.
Sep 30 07:05:11 ats traffic_server[6946]: NOTE: --- traffic_server 
Starting ---
Sep 30 07:05:11 ats traffic_server[6946]: NOTE: traffic_server 
Version: Apache Traffic Server - traffic_server - 5.0.1 - (build # 
7259 on Aug 25 2014 at 09:27:18)
Sep 30 07:05:11 ats traffic_server[6946]: NOTE: Unable to set 
RLIMIT_NOFILE(7):cur(-611778560),max(-611778560)
Sep 30 07:05:13 ats traffic_manager[6938]: {0xb708b6d0} ERROR: 
[LocalManager::pollMgmtProcessServer] Server Process terminated due to 
Sig 11: Segmentation fault
Sep 30 07:05:13 ats traffic_manager[6938]: {0xb708b6d0} ERROR: 
[Alarms::signalAlarm] Server Process was reset



Any idea where to look for to solve this problem ?

Thanks a lot !

Matt