Re: [openssl-dev] MSVC 2015 internal compiler error

[Erik Forsberg]

I also noticed compiler warnings generated by this code using SunStudio 
compilers.
This patch fixes those for me and seems to do the correct thing. Maybe it
makes the VC compiler work too ?

*** lhash.h Thu Jan 14 01:51:33 2016
--- ../../../x64/include/openssl//lhash.h   Wed Jan 27 15:09:47 2016
***
*** 99,105 
  unsigned long name##_LHASH_HASH(const void *);
  # define IMPLEMENT_LHASH_HASH_FN(name, o_type) \
  unsigned long name##_LHASH_HASH(const void *arg) { \
! const o_type *a = arg; \
  return name##_hash(a); }
  # define LHASH_HASH_FN(name) name##_LHASH_HASH
  
--- 99,105 
  unsigned long name##_LHASH_HASH(const void *);
  # define IMPLEMENT_LHASH_HASH_FN(name, o_type) \
  unsigned long name##_LHASH_HASH(const void *arg) { \
! o_type *a = (o_type *) arg; \
  return name##_hash(a); }
  # define LHASH_HASH_FN(name) name##_LHASH_HASH
  
***
*** 108,115 
  int name##_LHASH_COMP(const void *, const void *);
  # define IMPLEMENT_LHASH_COMP_FN(name, o_type) \
  int name##_LHASH_COMP(const void *arg1, const void *arg2) { \
! const o_type *a = arg1; \
! const o_type *b = arg2; \
  return name##_cmp(a,b); }
  # define LHASH_COMP_FN(name) name##_LHASH_COMP
  
--- 108,115 
  int name##_LHASH_COMP(const void *, const void *);
  # define IMPLEMENT_LHASH_COMP_FN(name, o_type) \
  int name##_LHASH_COMP(const void *arg1, const void *arg2) { \
! o_type *a = (o_type *) arg1; \
! o_type *b = (o_type *) arg2; \
  return name##_cmp(a,b); }
  # define LHASH_COMP_FN(name) name##_LHASH_COMP
  
***
*** 118,125 
  void name##_LHASH_DOALL_ARG(void *, void *);
  # define IMPLEMENT_LHASH_DOALL_ARG_FN(name, o_type, a_type) \
  void name##_LHASH_DOALL_ARG(void *arg1, void *arg2) { \
! o_type *a = arg1; \
! a_type *b = arg2; \
  name##_doall_arg(a, b); }
  # define LHASH_DOALL_ARG_FN(name) name##_LHASH_DOALL_ARG
  
--- 118,125 
  void name##_LHASH_DOALL_ARG(void *, void *);
  # define IMPLEMENT_LHASH_DOALL_ARG_FN(name, o_type, a_type) \
  void name##_LHASH_DOALL_ARG(void *arg1, void *arg2) { \
! o_type *a = (o_type *) arg1; \
! a_type *b = (o_type *) arg2; \
  name##_doall_arg(a, b); }
  # define LHASH_DOALL_ARG_FN(name) name##_LHASH_DOALL_ARG
  

>-- Original Message --
>
>On Sat, Jan 16, 2016 at 11:42:52AM +0100, Gisle Vanem wrote:
>> While building OpenSSL from today's git-repo:
>> 
>> ssl\d1_srtp.c : fatal error C1001: An internalerror has occurred in the 
>> compiler.
>> (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 246)
>>  To work around this problem, try simplifying or changing the program near 
>> the locations listed above.
>> Please choose the Technical Support command on the Visual C++
>>  Help menu, or open the Technical Support help file for more information
>> 
>> INTERNAL COMPILER ERROR in 'f:\gv\VC_2015\bin\cl.exe'
>> Please choose the Technical Support command on the Visual C++
>> Help menu, or open the Technical Support help file for more information
>> 
>> -
>> 
>> Seems to be related to:
>>   typedef const char *OPENSSL_CSTRING;
>> 
>> in safestack.h Changing this into:
>> 
>>   #ifdef _MSC_VER
>>   typedef   char *OPENSSL_CSTRING;
>>   #else
>>   typedef const char *OPENSSL_CSTRING;
>>   #endif
>> 
>> helps, but triggers the same internal compiler error later on.
>> 
>> It suspect the compiler sees 'const const *x' in some
>> places. So I assume that's the trigger for this fault.
>
>So we've been seeing this on AppVeyor too.  As far as I can see,
>this happens somewhere between commit 249d9719 and 59fd40d4.  The
>file itself has only minor changes, turning some "SSL_CIPHER *"
>into "const SSL_CIPHER *", so it's most likely one of the include
>files that changed in between.
>
>It includes changes to safestack, including adding inline
>functions instead of the defines.  So that is probably why it
>fails, but I currently don't see a way to work around this, or how
>we could simplify things.
>
>The problem also only seems to have with VC 14/2015.  It works in
>all the older versions we have on AppVeyor.
>
>Have you actually tried to contact Microsoft about this issue?
>
>
>Kurt
>
>___
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] unexpected message, SSL alert 10

[Michel]

Hi,

 

Doing some OpenSSL 1.1 pre-2 tests between a client and a server I got :

client : error:141600F4:SSL routines:read_state_machine:unexpected message

server : error:140943F2:SSL routines:ssl3_read_bytes:reason(1010); SSL alert
number 10

 

As I read somewhere that this alert should never be observed between proper
implementations, I thought best to report it.

 

What I did :

Neither client or server context was initialisied with certificates or key.

(I wanted to test anonymous ciphers)

But I erroneously used SSL_CTX_set_verify() with  SSL_VERIFY_PEER |
SSL_VERIFY_FAIL_IF_NO_PEER_CERT;

(server side).

 

Let me know if you need more informations.

 

Regards,

 

Michel 

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] MSVC 2015 internal compiler error

[Kurt Roeckx]

On Sat, Jan 16, 2016 at 11:42:52AM +0100, Gisle Vanem wrote:
> While building OpenSSL from today's git-repo:
> 
> ssl\d1_srtp.c : fatal error C1001: An internalerror has occurred in the 
> compiler.
> (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 246)
>  To work around this problem, try simplifying or changing the program near 
> the locations listed above.
> Please choose the Technical Support command on the Visual C++
>  Help menu, or open the Technical Support help file for more information
> 
> INTERNAL COMPILER ERROR in 'f:\gv\VC_2015\bin\cl.exe'
> Please choose the Technical Support command on the Visual C++
> Help menu, or open the Technical Support help file for more information
> 
> -
> 
> Seems to be related to:
>   typedef const char *OPENSSL_CSTRING;
> 
> in safestack.h Changing this into:
> 
>   #ifdef _MSC_VER
>   typedef   char *OPENSSL_CSTRING;
>   #else
>   typedef const char *OPENSSL_CSTRING;
>   #endif
> 
> helps, but triggers the same internal compiler error later on.
> 
> It suspect the compiler sees 'const const *x' in some
> places. So I assume that's the trigger for this fault.

So we've been seeing this on AppVeyor too.  As far as I can see,
this happens somewhere between commit 249d9719 and 59fd40d4.  The
file itself has only minor changes, turning some "SSL_CIPHER *"
into "const SSL_CIPHER *", so it's most likely one of the include
files that changed in between.

It includes changes to safestack, including adding inline
functions instead of the defines.  So that is probably why it
fails, but I currently don't see a way to work around this, or how
we could simplify things.

The problem also only seems to have with VC 14/2015.  It works in
all the older versions we have on AppVeyor.

Have you actually tried to contact Microsoft about this issue?


Kurt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Using openssl to check for cert reovcation using OCSP

[Salz, Rich]

> If this is not the correct forum to ask this question, can someone please 
> point
> me to the right direction.

You might try openssl-users.
 


> My question is that do I need to write my function to call OpenSSL to use
> OCSP to check if a certificate is revoked or I can configure OpenSSL to check
> this by setting flag in openssl.cnf?

You have to write your own code. Openssl does not fetch things automatically.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] MSVC 2015 internal compiler error

[Gisle Vanem]

Kurt Roeckx wrote:

> So we've been seeing this on AppVeyor too.  As far as I can see,
> this happens somewhere between commit 249d9719 and 59fd40d4.  The
> file itself has only minor changes, turning some "SSL_CIPHER *"
> into "const SSL_CIPHER *", so it's most likely one of the include
> files that changed in between.
> 
> It includes changes to safestack, including adding inline
> functions instead of the defines.  So that is probably why it
> fails, but I currently don't see a way to work around this, or how
> we could simplify things.

I haven't tried Erik Forsberg's patch for lhash.h. And have no
time to look into this. I use TDM-gcc in the meantime.

> Have you actually tried to contact Microsoft about this issue?

No, for the reason above.

-- 
--gv
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] ECDH engine

[Alexander Gostrer]

Hi Uri,

On Wed, Jan 27, 2016 at 9:30 AM, Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> Let me know if you have any questions about these patches.
>
>
> My only questions at this time (I briefly looked at your patches only,
> haven’t looked at your engine at all) are: why you needed to add
> ECDH\generate key() to crypto/ech/ecdh_key.c,
>

In the TLS-1.2 protocol (sl_srvr.c) the server generates an ephemeral key
pair for ECDH and sends the public key in the server key exchange message
(see ssl3_send_server_key_exchange(SSL *s) function). It does not use the
private key until it gets the client public key in the
"ssl3_send_server_key_exchange(SSL *s)". Just then it calls the
"ECDH_compute_key()" with the client public key and the server private key
generated much earlier. If I do not call this new function then the openssl
sends a software-generated ephemeral key to the client. Adding this
function was the simplest way to fix the problem. On client everything
happens in the same function so it wasn't a problem.


> and what’s the purpose of enabling (*init)(EC_KEY *eckey) and (*finish)(EC_KEY
> *eckey) in crypto/ecdh/ech_locl.h.
>

I used "ecdh->meth->init(eckey)" in this new "ECDH_generate_key(EC_KEY
*eckey)" function to actually generate the ephemeral pair. Probably should
call it "generate_key()" instead but again was trying to minimize the
impact. "finish()" was in the same package - didn't use it.

Regards,
Alex.
Sorry for delay: take some time to go over the code to remember things :)

>
> Thanks!
>
>
> On Wed, Jan 20, 2016 at 12:49 PM, Douglas E Engert 
> wrote:
>
>> When I started to write the ECDSA code for engine_pkcs11  in 2011 the
>> code to support the method hooks was not
>> in the code. So I used internal OpenSSL header files to copy the
>> ECDSA_METHOD  and replace the function needed.
>> Look for "BUILD_WITH_ECS_LOCL_H" in libp11.  Not until 1.0.2 did OpenSSL
>> support the needed calls to hook ECDSA.
>> They did not add the hooks for ECDH.
>>
>> If you can't wait then you have to do it your self.  *YOU* could do the
>> same thing for ECDH. But your code would only
>> be good for 1.0.2 because the whole way of doing EC methods changes in
>> 1.1.
>>
>> I believe Alexander said he had changes to OpenSSL, which is another
>> approach.
>> He has said there were here:
>> https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches
>>
>> You could also hire someone who could do more then: "test it and offer
>> minor enhancements".
>> (And not me. I am taking the 1.1 approach to getting ECDH. working in
>> engine.)
>>
>> On 1/20/2016 2:19 PM, Blumenthal, Uri - 0553 - MITLL wrote:
>>
>> Very possible that I'm missing the point here.
>>
>> Still, since openssl-1_0_2 does ECDH, and it exposes ‎ECDSA to external
>> engine(s), how difficult would it be to add ECDH exposure? I suspect - a
>> good deal easier than getting 1.1 replace 1.0.x as the de-facto deployment
>> standard.
>>
>> Plus, by this time there already are (and reasonably common) tokens that
>> support ECDH, other packages that do ECDH, and people (like myself :-)
>> willing to test it and offer minor enhancements.
>>
>> Another point I seem to be missing - if what's necessary to implement
>> ECDH in an external engine is missing from 1_0_2 - how could ‎Alexander
>> write a (presumably) working ECDH engine for 1_0_2? If he could do it,  why
>> can't engine_pkcs11 be extended to do the same?
>>
>>
>> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
>> *From: *Douglas E Engert
>> *Sent: *Wednesday, January 20, 2016 14:59
>> *To: *openssl-dev@openssl.org‎
>> *Reply To: *openssl-dev@openssl.org
>> *Subject: *Re: [openssl-dev] ECDH engine
>> ‎
>> You are missing the point. OpenSSL-1.0.2 only exposed ECDSA, not ECDH to
>> external engines.  It took years to even get ECDSA exposed.
>> OpenSSL approach to support this is OpenSSL-1.1  that does a lot of other
>> things. But that was there approach. Its their package.
>> >From working package to distribution always takes several years...
>>
>>
>>
>>
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4275] Test all built-in curves and let the library choose the EC_METHOD

[Billy Brumley via RT]

https://github.com/openssl/openssl/pull/592

Some of the other unit tests specify EC_METHOD. This additional test
loop lets the library choose based on the default for the built-in
curve's NID.

BBB


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Verification of ABI compatibility

[John Foley]

If anyone is interested, I've added a new build to the Jenkins workflow 
to verify ABI compatibility on the 1.0.2-stable branch. This job will 
run nightly and look for ABI differences between the current build and 
the build from the previous night.  If a commit goes into the branch 
that changes ABI, this job should alert the openssl-commits alias.


This results of this job can be viewed here:

https://openssl-sanity.cisco.com:8443/view/1.0.2%20Stable/job/1_0_2_abi/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Verification of ABI compatibility

[Salz, Rich]

Way cool.  Can you send mail to openssl-commits also?

--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz


> -Original Message-
> From: John Foley [mailto:fol...@cisco.com]
> Sent: Wednesday, January 27, 2016 11:10 AM
> To: openssl-dev@openssl.org
> Subject: [openssl-dev] Verification of ABI compatibility
> 
> If anyone is interested, I've added a new build to the Jenkins workflow to
> verify ABI compatibility on the 1.0.2-stable branch. This job will run nightly
> and look for ABI differences between the current build and the build from
> the previous night.  If a commit goes into the branch that changes ABI, this
> job should alert the openssl-commits alias.
> 
> This results of this job can be viewed here:
> 
> https://openssl-sanity.cisco.com:8443/view/1.0.2%20Stable/job/1_0_2_abi/
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] ECDH engine

[Blumenthal, Uri - 0553 - MITLL]

> Let me know if you have any questions about these patches.

My only questions at this time (I briefly looked at your patches only,
haven’t looked at your engine at all) are: why you needed to add
ECDH\generate key() to crypto/ech/ecdh_key.c, and what’s the purpose of
enabling (*init)(EC_KEY *eckey) and (*finish)(EC_KEY *eckey) in
crypto/ecdh/ech_locl.h.

Thanks!


> On Wed, Jan 20, 2016 at 12:49 PM, Douglas E Engert  wrote:
>> When I started to write the ECDSA code for engine_pkcs11  in 2011 the code to
>> support the method hooks was not
>> in the code. So I used internal OpenSSL header files to copy the ECDSA_METHOD
>> and replace the function needed.
>> Look for "BUILD_WITH_ECS_LOCL_H" in libp11.  Not until 1.0.2 did OpenSSL
>> support the needed calls to hook ECDSA.
>> They did not add the hooks for ECDH.
>> 
>> If you can't wait then you have to do it your self.  *YOU* could do the same
>> thing for ECDH. But your code would only
>> be good for 1.0.2 because the whole way of doing EC methods changes in 1.1.
>> 
>> I believe Alexander said he had changes to OpenSSL, which is another
>> approach. 
>> He has said there were here:
>> https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches
>> 
>> You could also hire someone who could do more then: "test it and offer minor
>> enhancements".
>> (And not me. I am taking the 1.1 approach to getting ECDH. working in
>> engine.) 
>> 
>> On 1/20/2016 2:19 PM, Blumenthal, Uri - 0553 - MITLL wrote:
>>> Very possible that I'm missing the point here.
>>> 
>>> Still, since openssl-1_0_2 does ECDH, and it exposes ‎ECDSA to external
>>> engine(s), how difficult would it be to add ECDH exposure? I suspect - a
>>> good deal easier than getting 1.1 replace 1.0.x as the de-facto deployment
>>> standard.
>>> 
>>> Plus, by this time there already are (and reasonably common) tokens that
>>> support ECDH, other packages that do ECDH, and people (like myself :-)
>>> willing to test it and offer minor enhancements.
>>> 
>>> Another point I seem to be missing - if what's necessary to implement ECDH
>>> in an external engine is missing from 1_0_2 - how could ‎Alexander write a
>>> (presumably) working ECDH engine for 1_0_2? If he could do it,  why can't
>>> engine_pkcs11 be extended to do the same?
>>> 
>>> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE
>>> network.
>>> From: Douglas E Engert
>>> Sent: Wednesday, January 20, 2016 14:59
>>> To: openssl-dev@openssl.org‎
>>> Reply To: openssl-dev@openssl.org
>>> Subject: Re: [openssl-dev] ECDH engine
>>> ‎
>>> You are missing the point. OpenSSL-1.0.2 only exposed ECDSA, not ECDH to
>>> external engines.  It took years to even get ECDSA exposed.
>>> OpenSSL approach to support this is OpenSSL-1.1  that does a lot of other
>>> things. But that was there approach. Its their package.
 >From working package to distribution always takes several years...
>>> 
>>> 
>>> 
> 




smime.p7s
Description: S/MIME cryptographic signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open

[Salz, Rich]

> What attack do you have in mind via spreading a cookie good for just one
> source IP address?  Sure the botnet can source TFO from that same IP
> address that got the original cookie.  Why is that useful?

It's an amplification attack.  I don't care about ever getting any reply back.  
As I first said, it makes UDP-style attacks possible in the TCP domain, and you 
don't know where the attack is coming from.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open

[Viktor Dukhovni]

On Wed, Jan 27, 2016 at 07:07:36PM +, Salz, Rich wrote:

> > What attack do you have in mind via spreading a cookie good for just one
> > source IP address?  Sure the botnet can source TFO from that same IP
> > address that got the original cookie.  Why is that useful?
> 
> It's an amplification attack.  I don't care about ever getting any reply
> back.  As I first said, it makes UDP-style attacks possible in the TCP
> domain, and you don't know where the attack is coming from.

Please explain.  The traffic can only come from the party who
initially obtains the cookie in a full round-trip.  How does the
botnet DoS some third party with this?

Or is it just the slightly larger response size in the server's
SYN-ACK + cookie vs. SYN-ACK on the initial cookie request?

A reasonably secure HMAC need not be longer that 256 bits or 32
bytes, so the SYN-ACK is larger by 32 bytes + a couple of bytes of
option encapsulation.  If that's all, UDP is far more effective.

Anyway, this has little relevance to support of TFO in OpenSSL,
the attack is the same whether we support SSL handshakes with
TFO or not.

-- 
Viktor.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open

[Salz, Rich]

> Please explain.  The traffic can only come from the party who initially 
> obtains
> the cookie in a full round-trip.  How does the botnet DoS some third party
> with this?

Attacker wants to bring down an akamai host.  They connect to one of our 
servers with the fast-open option and get the cookie.  They then spread that 
cookie all over the internet and zillions of bots connect.  Our server spawns 
zillions of threads and starts to do some work, or the TCP queue fills up.  I 
can't filter on IP address to stop the attack because the client IP address is 
bogus.

It's just like a DNS/UDP attack, except at the TCP layer which much software is 
not prepared to handle.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open

[Viktor Dukhovni]

On Wed, Jan 27, 2016 at 02:19:32PM +, Salz, Rich via RT wrote:
> 
> > This suggests that you have on-path capabilities between each of the
> > reflectors and the victim, right?
> 
> I don't think so:  you need the first attacker to get the cookie, then you 
> spread it out.

   Cheng, et al. Experimental  [Page 8]
   RFC 7413  TCP Fast OpenDecember 2014

   The server is in charge of cookie generation and authentication.  The
   cookie SHOULD be a MAC tag with the following properties.  We use
   "SHOULD" because, in some cases, the cookie may be trivially
   generated as discussed in Section 7.3.

   1. The cookie authenticates the client's (source) IP address of the
  SYN packet.  The IP address may be an IPv4 or IPv6 address.

   2. The cookie can only be generated by the server and cannot be
  fabricated by any other parties, including the client.

   3. The generation and verification are fast relative to the rest of
  SYN and SYN-ACK processing.

   4. A server may encode other information in the cookie and accept
  more than one valid cookie per client at any given time.  But this
  is server-implementation dependent and transparent to the client.

   5. The cookie expires after a certain amount of time.  The reason for
  cookie expiration is detailed in the "Security Considerations"
  section (Section 5).  This can be done by either periodically
  changing the server key used to generate cookies or including a
  timestamp when generating the cookie.

  To gradually invalidate cookies over time, the server can
  implement key rotation to generate and verify cookies using
  multiple keys.  This approach is useful for large-scale servers to
  retain Fast Open rolling key updates.  We do not specify a
  particular mechanism because the implementation is server
  specific.

What attack do you have in mind via spreading a cookie good for
just one source IP address?  Sure the botnet can source TFO
from that same IP address that got the original cookie.  Why is
that useful?

-- 
Viktor.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open

[Viktor Dukhovni]

On Wed, Jan 27, 2016 at 07:20:04PM +, Salz, Rich wrote:

> > Please explain.  The traffic can only come from the party who initially 
> > obtains
> > the cookie in a full round-trip.  How does the botnet DoS some third party
> > with this?
> 
> Attacker wants to bring down an akamai host.  They connect to one of our
> servers with the fast-open option and get the cookie.  They then spread
> that cookie all over the internet and zillions of bots connect.

The connections need to be from the attacker's original IP address that
obtained the cookie.

> Our server
> spawns zillions of threads and starts to do some work, or the TCP queue
> fills up.  I can't filter on IP address to stop the attack because the
> client IP address is bogus.

The client IP address is not entirely "bogus", it is the IP address
of the client that obtained the cookie, otherwise the cookie is
not valid.  Block sending cookies to sources whose cookies are
abused.

Also note that the TFO queue length is limited, and most requests
will require a full round-trips when the request volume is high.

Anyway, this is not the right forum for TFO threat analysis that
has nothing to do with SSL.  We should add client-side support
for TFO.

-- 
Viktor.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open

[Salz, Rich via RT]

> This suggests that you have on-path capabilities between each of the
> reflectors and the victim, right?

I don't think so:  you need the first attacker to get the cookie, then you 
spread it out.
 
> If you have on-path capabilities, couldn't you do a similar attack against a 
> live
> TCP session?

Different because there you are interrupting a session, whereas with TFO you're 
starting a new connection and pushing data to the receiving app on a "new" 
connection.



___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev