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
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
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
> 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
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
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
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:
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
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
>
> 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
> 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
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
> 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
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.
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.
> 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
16 matches
Mail list logo
