: HTTP. Last updated 2017-03-18.
|
|
|
http://www.chromium.org/developers/design-documents/secure-web-proxy
When clients support talking HTTPS directly to proxy, setting up ATS to
terminate SSL should be based on the docs you already looked at.
It's really up to the client though and I
I followed the document to setup certs and keys for ATS. But it does not seem
to take these and terminate SSL in forward mode.
My understand with forward proxy is that UA sends a CONNECT command first, ATS
establishs a tunnel between UA and origin server.
My question is how is the termination
That's right, what we need are SSL attributes like the protocol version or
the cipher used
On Wed, Jul 17, 2019, 23:16 Sudheer Vinukonda
wrote:
> Oh, it looks like the goal is to actually get SSL context attributes for
> a given TXN and not so much _STATS_. Sorry, I was confused by
Oh, it looks like the goal is to actually get SSL context attributes for a
given TXN and not so much _STATS_. Sorry, I was confused by the use of word
_STAT_ and assumed you were trying to collect metrics/counters.
Assuming it is the SSL Context attributes for a TXN that you are looking to
get
APIs that can return
> any stat (defined as an ENUM for example)?
> >
> >
> > On Tuesday, July 16, 2019, 11:07:19 AM PDT, Valentín Gutierrez <
> vgutier...@wikimedia.org> wrote:
> >
> > Hi,
> >
> > We need to expose several client request SSL stats
7:19 AM PDT, Valentín Gutierrez
> wrote:
>
> Hi,
>
> We need to expose several client request SSL stats that are currently
> being gathered in the HttpSM to the Lua plugin. To achieve this I'd
> like to propose adding several functions to the API:
>
> int TSHttp
several client request SSL stats that are currently
being gathered in the HttpSM to the Lua plugin. To achieve this I'd
like to propose adding several functions to the API:
int TSHttpTxnClientReqIsSslReused(TSHttpTxn txnp);
const char *TSHttpTxnClientReqSslCipherGet(TSHttpTxn txnp);
const
Hi,
We need to expose several client request SSL stats that are currently
being gathered in the HttpSM to the Lua plugin. To achieve this I'd
like to propose adding several functions to the API:
int TSHttpTxnClientReqIsSslReused(TSHttpTxn txnp);
const char *TSHttpTxnClientReqSslCiph
+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 o
+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
>
+1
On Thu, Jun 6, 2019 at 5:51 PM Steven R. Feltner
wrote:
> +1
>
> On 6/6/19, 8: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
+1
On 6/6/19, 8: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
+1
Totally Agree - a much straightforward vote than disabling tlsv1.1 :=)
> 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
+1
On Thursday, June 6, 2019, 5:32:10 PM PDT, 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
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
I think the main barrier to good documentation is the amount of reverse
engineer it would require at this point.
I've never found Doxygen to be so helpful but also have not used it much.
Unlike other languages such as Java, C++ is designed to allow separating
interface from implementation, so bett
Here are the prototypes with comments:
/**
* This function retrieves an array of lookup keys for client contexts
loaded in
* traffic server. Given a 2-level mapping for client contexts, every 2
lookup keys
* can be used to locate and identify 1 context.
* @param n Allocated size for result arr
Yes, although doxylink requires a couple of patches to work well with
C++17. I have PRs up on the repo for those fixes, but need to find time to
write some unit tests to get them accepted.
The goal is to have Doxygen generate reference material, while Sphinx
provides higher level descriptions of t
Alan do you mean this? https://pythonhosted.org/sphinxcontrib-doxylink/
On Thu, May 2, 2019 at 9:21 AM Leif Hedstrom wrote:
>
>
> > On May 2, 2019, at 08:17, Alan Carroll
> wrote:
> >
> > Yes they can work together. I presented on that at the Summit, you should
> > have been there.
>
> I shoul
> On May 2, 2019, at 08:17, Alan Carroll
> wrote:
>
> Yes they can work together. I presented on that at the Summit, you should
> have been there.
I should have.
So is that setup today? Where does it go? How does it synergize with all
existing API docs?
And, stop inlining Doxygen comments
Yes they can work together. I presented on that at the Summit, you should
have been there.
On Thu, May 2, 2019 at 9:15 AM Leif Hedstrom wrote:
> +1 on docs.
>
> However , I think it’s a bit of a mess now with Doxygen sometimes, and
> normal Sphinx docs (most of the time?). It seems we should hav
+1 on docs.
However , I think it’s a bit of a mess now with Doxygen sometimes, and normal
Sphinx docs (most of the time?). It seems we should have one way of documenting
our interfaces and APIs, no? I find often times, Doxygen can get in the way of
code formatting / indentation, specially when
They shouldn't become invalid during the callback invocation, but may after
the callback returns.
As for Doxygen, perhaps I am simply weird in that I like to have
documentation for API that I call. I guess I'm just not smart enough to
deduce the meaning and function from only the function and para
Talked with Zeyuan, he clarified that an example call would be something
like:
const char *ctx[666];
int n_actual_ctx;
rc = TSSslClientContextsGet(666, ctx, &n_actual_ctx);
I don't know enough about SSL to know when the pointers in ctx[] would
become dangling.
On Wed, May 1, 2019 a
Doxygen is all that at sign business? Been here almost 2 years first time
I heard it's required. Zwoop did thank me for not doing that.
On Wed, May 1, 2019 at 4:59 PM Alan Carroll
wrote:
> Um, any detail on what the parameters are? Doxygen comments should be the
> minimum provided.
>
> On Wed,
Um, any detail on what the parameters are? Doxygen comments should be the
minimum provided.
On Wed, May 1, 2019 at 2:55 PM Zeyuan Yu wrote:
> Alan and Walt pointed out the API needs to be C. Here are the new
> prototypes:
>
> TSReturnCode TSSslClientContextsGet(int n, const char **result, int
>
Alan and Walt pointed out the API needs to be C. Here are the new
prototypes:
TSReturnCode TSSslClientContextsGet(int n, const char **result, int *actual)
;
TSSslContext TSSslClientContextFind(const char *name);
[image: work-eat-sleep--400090.jpg]
*Zeyuan Yu*
Software Development Engineer, Veri
vector TSSslClientContextsGet();
TSSslContext TSSslClientContextFind(const string name);
ATS has APIs for server context retrieval (TSSslContextFindByName(),
TSSslContextFindByAddr()). It would be useful to expose client context via
APIs too.
I would like to propose new APIs for this purpose. Gi
The point is that due to the openSSL API, it is not possible in all
situations for a Continuation to be queued for later execution.
As for the type, we already have a transform specific continuation creation
call (TSTransformCreate), we could do something similar to TLS hook
continuations.
l cost of
> blocking the thread.
>
> We could block and issue a warning on the hook call to give people some
> hint that this might be a performance problem.
>
> On Fri, Feb 8, 2019, 7:21 PM Bryan Call
> Couldn’t you change the lock to be a blocking lock for the SSL APIs?
>
>
g a TSCont that doesn't have a mutex.
>>>
>>> On Fri, Feb 8, 2019 at 7:38 PM Susan Hinrichs
>>> wrote:
>>>
>>>> Yes, we could blocking lock easily enough too at the potential cost of
>>>> blocking the thread.
>>>>
>>>>
chs
> > wrote:
> >
> >> Yes, we could blocking lock easily enough too at the potential cost of
> >> blocking the thread.
> >>
> >> We could block and issue a warning on the hook call to give people some
> >> hint that this might be a performa
t the potential cost of
>> blocking the thread.
>>
>> We could block and issue a warning on the hook call to give people some
>> hint that this might be a performance problem.
>>
>> On Fri, Feb 8, 2019, 7:21 PM Bryan Call >
>>> Couldn’t you chang
potential cost of
> > blocking the thread.
> >
> > We could block and issue a warning on the hook call to give people some
> > hint that this might be a performance problem.
> >
> > On Fri, Feb 8, 2019, 7:21 PM Bryan Call >
> > > Couldn’t you change th
d issue a warning on the hook call to give people some
> hint that this might be a performance problem.
>
> On Fri, Feb 8, 2019, 7:21 PM Bryan Call
> > Couldn’t you change the lock to be a blocking lock for the SSL APIs?
> >
> > It seems like a bad interface to
blocking lock for the SSL APIs?
>
> It seems like a bad interface to be able to write and compile code that
> will assert later on.
>
> -Bryan
>
> > On Feb 7, 2019, at 2:51 PM, Susan Hinrichs wrote:
> >
> > @macisasandwich ran into this when working with port ready c
Couldn’t you change the lock to be a blocking lock for the SSL APIs?
It seems like a bad interface to be able to write and compile code that will
assert later on.
-Bryan
> On Feb 7, 2019, at 2:51 PM, Susan Hinrichs wrote:
>
> @macisasandwich ran into this when working with port read
are asking for a
lot more trouble and plugin writer pain down the road than this will cause.
On Thu, Feb 7, 2019 at 4:51 PM Susan Hinrichs wrote:
> @macisasandwich ran into this when working with port ready changes in
> autest. The extra port probe tied up the test ssl plugin (for tls_hooks1
@macisasandwich ran into this when working with port ready changes in
autest. The extra port probe tied up the test ssl plugin (for tls_hooks15)
which exercised a TLS hook on a continuation with a mutex. Since the invoke
method could not grab the lock, the assertion went off.
I went back to look
v 2, 2018 at 11:41 AM Dk Jack wrote:
>>
>> Hi,
>> I enabled SSL on my ATS and my ssl requests are failing with handshake
>> error. From the logs I can tell that it loaded my cert/key correct. When I
>> started traffic server in debug mode (./traffic_se
Is your client sending a TLSv1.2 handshake? Maybe it's a lower version or
non TLS.
On Fri, Nov 2, 2018 at 11:41 AM Dk Jack wrote:
> Hi,
> I enabled SSL on my ATS and my ssl requests are failing with handshake
> error. From the logs I can tell that it loaded my cert/key correct. Wh
ficate in the debug logs. I've prefixed the important lines in
> the
> > debug log with '=>'.
> >
> > Dk.
> >
> > ------
> > > openssl s_client -host 10.3.27.19 -port 7453
> > CONNE
-
> > openssl s_client -host 10.3.27.19 -port 7453
> CONNECTED(0003)
> 140260354160280:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
> alert handshake failure:s23_clnt.c:769:
> ---
> no peer certificate available
g log with '=>'.
Dk.
--
> openssl s_client -host 10.3.27.19 -port 7453
CONNECTED(0003)
140260354160280:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:769:
---
no peer certificate available
---
No client certificate CA n
I'd start with "openssl s_client" to get more debug information, followed
possibly by a packet capture to be sure the user agent is connecting with
TLS to a TLS enabled proxy port.
On Fri, Nov 2, 2018 at 1:41 PM Dk Jack wrote:
> Hi,
> I enabled SSL on my ATS and my ssl requ
Hi,
I enabled SSL on my ATS and my ssl requests are failing with handshake
error. From the logs I can tell that it loaded my cert/key correct. When I
started traffic server in debug mode (./traffic_server -T ssl), I am seeing
the following error
SSL routines:ssl3_get_client_hello:no shared cipher
he
> Traffic Server session cache (option 2 in proxy.config.ssl.session_cache)"
> is incorrect and should be removed from our docs.
>
> On Tue, Oct 9, 2018 at 9:09 PM Dk Jack wrote:
>
> > Hi,
> > I am trying to understand the ssl cache timeout in ATS. According to the
On Tue, Oct 9, 2018 at 9:09 PM Dk Jack wrote:
> Hi,
> I am trying to understand the ssl cache timeout in ATS. According to the
> documentation for proxy.config.ssl.session_cache, a default value of 2 is
> chosen if its not configured. For proxy.config.ssl.session_cache.timeout, a
>
Hi,
I am trying to understand the ssl cache timeout in ATS. According to the
documentation for proxy.config.ssl.session_cache, a default value of 2 is
chosen if its not configured. For proxy.config.ssl.session_cache.timeout, a
default value of 0 is chosen, if its not configured which means ssl
All,
I've created a PR to address issue #2380 (Missing ssl session close hook)
and
#2388 (Ability to add contextual data on (Net)VConnections). Would
appreciate
a review. The PR includes includes API documentation as well for #2388 and
hence would appreciate a review for the documentation as
The PR should include documentation.
-Bryan
> On Oct 15, 2017, at 5:45 PM, SUSAN HINRICHS wrote:
>
> Hello everyone,
>
> I just put up a PR which implements the Hooks and TS API calls described in
> http://home.apache.org/~shinrich/docs/developer-guide/ssl-session-api.en.ht
I think this is fine. Let's do it.
On Sun, Oct 15, 2017 at 7:45 PM, SUSAN HINRICHS wrote:
> Hello everyone,
>
> I just put up a PR which implements the Hooks and TS API calls described in
> http://home.apache.org/~shinrich/docs/developer-guide/
> ssl-session-api.en.html
Hello everyone,
I just put up a PR which implements the Hooks and TS API calls described in
http://home.apache.org/~shinrich/docs/developer-guide/ssl-session-api.en.html
.
The PR is at https://github.com/apache/trafficserver/pull/2663
I hope to post an example plugin before the summit. Please
ower levels
> because, the lower levels (vconn, netvconn) are called after the ssl
> data-structures
> are cleaned up and I wanted the plugin callback to be synchronously so
> that user
> data can be cleaned up.
>
> Things are working for the most part. I am getting a
not bother with reserving since user can get the data using name.
- Added close hook for SSLNetVConnection. I couldn't add it to lower levels
because, the lower levels (vconn, netvconn) are called after the ssl
data-structures
are cleaned up and I wanted the plugin callback to be synchronous
aned up if
something goes wrong.
On Wed, Sep 27, 2017 at 4:29 PM, Dk Jack wrote:
> Yeah, I was thinking along similar lines...
>
> Do you think, it'd be a worth while effort to add a ssl-close event hook?
>
> On Wed, Sep 27, 2017 at 1:31 PM, Alan Carroll <
> soli
Yeah, I was thinking along similar lines...
Do you think, it'd be a worth while effort to add a ssl-close event hook?
On Wed, Sep 27, 2017 at 1:31 PM, Alan Carroll <
solidwallofc...@oath.com.invalid> wrote:
> I'd probably put a time stamp in and update it during the hook p
I'd probably put a time stamp in and update it during the hook processing.
If you waited 5 minutes or so before clearing, that should be enough. If
it's been 5 minutes since the last activity the connection should be dead,
unless you're shipping big files.
Or, alternatively, in READ_REQUEST_HDR_HO
st be some reliable way to clean it up.
>
> I'm not an SSL expert but something dangerous you could try is to see if
> there is an openSSL hook you can grab to do the cleanup. The dangerous part
> is it is likely the ATS core already has a callback in place so you'd need
> to retrieve that and call it from your hook.
>
I'm not an SSL expert but something dangerous you could try is to see if
there is an openSSL hook you can grab to do the cleanup. The dangerous part
is it is likely the ATS core already has a callback in place so you'd need
to retrieve that and call it from your hook.
);
Connection sslobj = TSVConnSSLConnectionGet(ssl_vc);
TSSslSSL *ssl = reinterpret_cast(sslobj);
...
}
I can allocate some memory off the heap and then store my ssl contextual
stuff in the openssl
ssl object using ssl apis...
https://www.openssl.org/docs/manmaster/man3/SSL_set_ex_data.html
Later in my
This is a known problem, see
https://github.com/apache/trafficserver/issues/2388 . The point of that
feature request is to be able to store data on the TSNetVConn (which you
have in the SSL hook) and then retrieve it later in an HTTP hook (from
which you can get to the same TSNetVConn). Currently
Hi,
I am adding a hook to get access to the ssl handshake data. I am using
something like:
TSHttpHookAdd(TS_SSL_CERT_HOOK, cb_cert);
In the ssl callback, I am extracting some info from the ssl connection and
I'd like to save the info. I'd like to later retrieve this info when my
Http
On 7/3/2016 10:17 AM, James Peach wrote:
On Jul 3, 2016, at 5:52 AM, shinrich wrote:
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/758
Previous discussion was on PR #750 Persia has addressed those issues, so I
think this good to go.
D
> On Jul 3, 2016, at 5:52 AM, shinrich wrote:
>
> Github user shinrich commented on the issue:
>
>https://github.com/apache/trafficserver/pull/758
>
>Previous discussion was on PR #750 Persia has addressed those issues, so
> I think this good to go.
Documentation?
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/758
---
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 featur
Github user atsci commented on the issue:
https://github.com/apache/trafficserver/pull/758
Linux build *successful*! See
https://ci.trafficserver.apache.org/job/Github-Linux/304/ for details.
---
If your project is set up for it, you can reply to this email and have your
reply
Github user atsci commented on the issue:
https://github.com/apache/trafficserver/pull/758
FreeBSD build *successful*! See
https://ci.trafficserver.apache.org/job/Github-FreeBSD/410/ for details.
---
If your project is set up for it, you can reply to this email and have your
r
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/758
[approve ci]
---
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,
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/758
Previous discussion was on PR #750 Persia has addressed those issues, so I
think this good to go.
---
If your project is set up for it, you can reply to this email and have your
reply appea
GitHub user persiaAziz opened a pull request:
https://github.com/apache/trafficserver/pull/758
TS-3371: Global variable for enabling SSL session ticket
Global variable proxy.config.ssl.server.session_ticket.enable added to
enable/disable the usage of SSL session ticket
You can
Github user shinrich commented on the pull request:
https://github.com/apache/trafficserver/pull/669#issuecomment-222003637
Merged up with commit 456ade9ab35787d39d3414149a0ee04f44008268
---
If your project is set up for it, you can reply to this email and have your
reply appear on Gi
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/669
---
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 featur
Github user shinrich commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/669#discussion_r64788248
--- Diff: proxy/http/Http1ClientSession.cc ---
@@ -427,9 +427,12 @@ Http1ClientSession::release(ProxyClientTransaction
*trans)
ka_vio = this-
Github user bryancall commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/669#discussion_r64785961
--- Diff: proxy/http/Http1ClientSession.cc ---
@@ -427,9 +427,12 @@ Http1ClientSession::release(ProxyClientTransaction
*trans)
ka_vio = this
Github user zwoop commented on the pull request:
https://github.com/apache/trafficserver/pull/669#issuecomment-221936130
Cool. Can you mark the Jira with back port to 6.1.2 as well as 6.2.0
please? I'll try to spend some time today and tomorrow to see what we should
get into a potenti
Github user SolidWallOfCode commented on the pull request:
https://github.com/apache/trafficserver/pull/669#issuecomment-221935663
I went through all the changes with Susan and I will +1 these changes.
---
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/669#issuecomment-221935540
Based on my research it would be an issue for 6.0 and 6.1 as well.
TS-3727 change was marked fixed for 6.0.
---
If your project is set up for it, you can rep
Github user SolidWallOfCode commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/669#discussion_r64783870
--- Diff: proxy/http/Http1ClientSession.cc ---
@@ -427,9 +427,12 @@ Http1ClientSession::release(ProxyClientTransaction
*trans)
ka_vio
Github user zwoop commented on the pull request:
https://github.com/apache/trafficserver/pull/669#issuecomment-221927293
@shinrich The Jira vs this PR has slightly different implications :). Is
this a 6.0 issue (i.e. would 6.1.x be affected by this) or is it only in 6.2.x
? I'm contem
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/669
TS-4661: SSL Client Connections not closed.
Ultimately the issue was that SSL connections that stall in the
ProtocolTrampoline never have the inactivity timeout cleanup. The problem was
Github user jpeach closed the pull request at:
https://github.com/apache/trafficserver/pull/661
---
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 maskit commented on the pull request:
https://github.com/apache/trafficserver/pull/661#issuecomment-221328309
Looks good to me.
---
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 thi
GitHub user jpeach opened a pull request:
https://github.com/apache/trafficserver/pull/661
TS-4108: Switch SSL metrics to RECD_COUNTER.
All the SSL metrics registered in SSLUtils.cc are specified as
RECD_INT, but they are all actually counters and should be specified
as
As discussed,
https://github.com/apache/trafficserver/pull/589
On Sat, Apr 16, 2016 at 10:46 AM Phil Sorber wrote:
> Ok, here is my final plan then. I am going to mark them all deprecated for
> 6.2.x.
>
> Then after branching I am going to remove all client <-> proxy support and
> ifdef out pro
Ok, here is my final plan then. I am going to mark them all deprecated for
6.2.x.
Then after branching I am going to remove all client <-> proxy support and
ifdef out proxy <-> origin support for SSLv3. SSLv2 will be totally gone.
Then add a configure option that reads something like
--enable-depr
Thanks Susan.
Karthik
On 3/30/16, 6:44 AM, "Susan Hinrichs" wrote:
>Yes, you can decrypt and proxy SSL traffic in forward mode. Typically
>(always?) this is done in transparent mode.
>
>http://trafficserver.readthedocs.org/en/latest/admin-guide/configurati
okAdd(TS_SSL_CERT_HOOK, cb_cert);
>
> There are several example plugins and the basic elements are documented in
> the API docs. Here is the original design document.
> http://network-geographics.com/ats/docs/ssl-api.en.html I think a couple of
> the constant names changed by the t
s the original design document.
http://network-geographics.com/ats/docs/ssl-api.en.html I think a
couple of the constant names changed by the time it got committed, but
this gives a good overview. It also points at the examples.
From the plugin callback you can cast the TS SSL object to an op
+1
nice to move forward
- Yongming Zhao 赵永明
> 在 2016年4月10日，下午8:42，Phil Sorber 写道：
>
> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> remove it in 7.0.0.
>
> Currently our defaults do not enable them and have been that way for about
> a year now. For 6.2.0 I'd like to
xy
but please keep sslv2/v3 for proxy <-> origin.
I'm implement a man in the middle ssl forward proxy with ats.
发自我的 iPhone
在 2016年4月11日，08:57，Uri Shachar 写道：
>> On Apr 10, 2016, at 7:42 AM, Phil Sorber wrote:
>>
>> I'd like to propose that we deprecate SSLv2 an
+1
On Tuesday, April 12, 2016 7:56 AM, Steven R. Feltner
wrote:
+1
> -Original Message-
> From: Phil Sorber [mailto:sor...@apache.org]
> Sent: Sunday, April 10, 2016 8:43 AM
> To: dev@trafficserver.apache.org; us...@trafficserver.apache.org
> Subject: Deprecat
+1
> -Original Message-
> From: Phil Sorber [mailto:sor...@apache.org]
> Sent: Sunday, April 10, 2016 8:43 AM
> To: dev@trafficserver.apache.org; us...@trafficserver.apache.org
> Subject: Deprecation of SSL v2/3
>
> I'd like to propose that we deprecate SSLv2
+1 to disable for client <-> proxy
but please keep sslv2/v3 for proxy <-> origin.
I'm implement a man in the middle ssl forward proxy with ats.
发自我的 iPhone
在 2016年4月11日，08:57，Uri Shachar 写道：
>> On Apr 10, 2016, at 7:42 AM, Phil Sorber wrote:
>>
>> I'd
+1
The consequences from DROWN (CVE-2016-0800 and CVE-2016-0703 ) are too severe
on the whole shared cert infrastructure from just one machine being
accidentally configured to allow SSLv2.
I filed this ticket:https://issues.apache.org/jira/browse/TS-4247
On Sunday, April 10, 2016 8:33
+1
2016年4月11日(月) 9:57 Uri Shachar :
> > On Apr 10, 2016, at 7:42 AM, Phil Sorber wrote:
> >
> > I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> > remove it in 7.0.0.
> >
> > Currently our defaults do not enable them and have been that way for
> about
> > a year now. For
> On Apr 10, 2016, at 7:42 AM, Phil Sorber wrote:
>
> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> remove it in 7.0.0.
>
> Currently our defaults do not enable them and have been that way for about
> a year now. For 6.2.0 I'd like to mark them deprecated in the
> docu
+1
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.ga...@brainsware.org
URL: https://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
On Sun, 10 Apr 2016, at 14:42, Phil Sorber wrote:
> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> remove
+1
> On Apr 10, 2016, at 8:42 AM, Phil Sorber wrote:
>
> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> remove it in 7.0.0.
>
> Currently our defaults do not enable them and have been that way for about
> a year now. For 6.2.0 I'd like to mark them deprecated in the
>
> On Apr 10, 2016, at 7:42 AM, Phil Sorber wrote:
>
> I'd like to propose that we deprecate SSLv2 and SSLv3 in ATS 6.2.0 and
> remove it in 7.0.0.
>
> Currently our defaults do not enable them and have been that way for about
> a year now. For 6.2.0 I'd like to mark them deprecated in the
> doc
1 - 100 of 312 matches
Mail list logo
