Github user asfgit closed the pull request at:
https://github.com/apache/trafficserver/pull/281
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
GitHub user ericcarlschwartz opened a pull request:
https://github.com/apache/trafficserver/pull/281
[TS-3534] Wiretracing for SSL connections (doc change only)
Just a doc change.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/er
Github user asfgit closed the pull request at:
https://github.com/apache/trafficserver/pull/246
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Github user ericcarlschwartz commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-120100458
@shinrich rebased off apache/master and opened a new PR for this here. this
one had some weirdness because of issues w/ apache/master and yahoo/master
be
Github user ericcarlschwartz closed the pull request at:
https://github.com/apache/trafficserver/pull/194
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if th
GitHub user ericcarlschwartz opened a pull request:
https://github.com/apache/trafficserver/pull/246
TS-3534 Wiretracing SSL Connections
Initial Commit
TS-3534 Cleanup before PR
remove tcp_info traces
fix sni server name
update rand mechanism and u
Github user ericcarlschwartz commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-120092663
@ushachar @shinrich I tend to agree that having some simple stuff available
as records.config settings for those who don't want to write a new plugin each
Github user ushachar commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-120083030
I think moving the entire "when to debug" logic to plugin space would be a
better idea -- yes.
Mostly in order to simplify the core code, but also to allow so
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-120036935
I think @ushachar is suggesting that this whole feature should be in a
plugin?
---
If your project is set up for it, you can reply to this email and have your
rep
Github user shinrich commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-119973950
@ushachar I agree with your comment about making the computeSSLTrace
decision accessible from the plugin. I read your earlier comment too quickly
and thought yo
Github user ushachar commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-119945084
I still think all the SSLNetVConnection::computeSSLTrace() logic should be
moved into plugin space - even if not extending TSHttpSsnDebugSet and keeping
this as
Github user shinrich commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-119679199
@ericcarlschwartz Nevermind. I just missed it the first time. Looks good.
---
If your project is set up for it, you can reply to this email and have your
reply
Github user ericcarlschwartz commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-119674972
@shinrich I added it to set_context_cert because it looks like both the
ssl_servername_callback and ssl_cert_callback will call that and it saves some
co
Github user shinrich commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-119546802
@ericcarlschwartz that sounds like a reasonable solution. I see that
you've done half of it by adding the if !(TS_USE_TLS_SNI) in the handshake code.
Yo
Github user ericcarlschwartz commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-119357789
@shinrich here's a proposed solution:
if TS_USE_TLS_SNI isn't set then we put the logic where you'd suggested. if
it is, we set the trace right a
Github user ericcarlschwartz commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-119345316
and for the non SNI-enabled case I can put it in the equivalent function in
the corresponding #else block
---
If your project is set up for it, you can
Github user ericcarlschwartz commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-119344998
@shinrich: did some testing there. the problem w/ putting it right in that
particular spot is that the return value from SSL_get_servername call will
alw
Github user ericcarlschwartz commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-119295104
Ah yes I remember that part of things in terms of what's stored where, was
just wondering how that worked exactly since the ssl_vc is in the faux
transac
Github user shinrich commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-119289670
For SPDY and H2 the underlying SSLNetVConnection is stored with the
SPDYClient and the Http2Client respectively. Multiple faux Http1.1
transactions are created
Github user ericcarlschwartz commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-119275969
@shinrich ah ok thanks for the comments. I'll make that first change today.
w.r.t. the second comment will have to think more about it. because we
Github user shinrich commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-119261713
The SNI name check looks better. A couple comments remaining.
computeSSLTrace() might be getting called more than once per transaction.
You are probabl
Github user ericcarlschwartz commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-115050303
@shinrich I think this is ready for another look if you or someone else has
some time.
---
If your project is set up for it, you can reply to this email
Github user bryancall commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-112873930
https://issues.apache.org/jira/browse/TS-3534
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If
Github user shinrich commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-105638387
I'm afraid I'm being a bit dense, but where is sslServerName ever set to a
non-null value?
---
If your project is set up for it, you can reply to this email and
Github user ericcarlschwartz commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-105593729
@RolandZink, yeah that's what I was thinking. I will do some searching and
see if something like that's been done before and how wireshark will behave
wi
Github user RolandZink commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-105592140
The log contains more than one key. When the browser writes it then there
is only one client but more than one server and wireshark can decrypt all the
connect
Github user ericcarlschwartz commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-105585945
I've dropped the tcp_info traces.
My understanding was in line with @sudheerv's that this was never intended
as a total replacement to using wire
Github user ericcarlschwartz commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-105575893
@sudheerv: the TCP_INFO usage can definitely be dropped because of the
associated cost/its only situational usefulness. i will prepare a patch with it
re
Github user RolandZink commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-105575681
With perfect forward secrecy getting the necessary keys becomes more
difficult. I made some better experience by getting the session keys from the
browsers. So
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-105570715
Well if you can configure logging on the ATS server, then it seems
reasonable that you would have access to the SSL keys.
---
If your project is set up for it, yo
Github user sudheerv commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-105570499
Yes, but, you would need to know/use the cert to do that, which is not
always straightforward - as I said, "the problem with existing tools is that
they can not
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-105569519
Wireshark decrypts SSL, https://wiki.wireshark.org/SSL.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as w
Github user sudheerv commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-97845539
I agree with @jpeach on the TCP_INFO usage. Are the TCP_INFO traces even
part of the wire trace feature? Besides being non-portable, isn't there also
(significant
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-97840771
I only looked quickly, but just a couple of points. The use of ``TCP_INFO``
is non-portable so this feature will need to be conditional. Why would we have
our own t
Github user ushachar commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-97664982
It would be better to move all the 'when to debug' logic into plugin space
-- you can extend the TSHttpSsnDebugSet API, hook a plugin on the SNI callback
and do w
Github user ericcarlschwartz commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-97163497
Right now this PR is multiple commits. I'll probably be adding to it as
people have suggestions for improvement. I can squash stuff down before
anything g
GitHub user ericcarlschwartz opened a pull request:
https://github.com/apache/trafficserver/pull/194
Ts 3534
Initial pull request for wiretracing v0. Please leave me your comments and
I'll make changes as necessary.
Looking into this now: Making sure we turn tracing off for
37 matches
Mail list logo
