<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: syzzer</title><link>https://news.ycombinator.com/user?id=syzzer</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Thu, 30 Apr 2026 20:15:28 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=syzzer" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by syzzer in "CVE-2021-27135: xterm flaw may allow remote code execution, CVSS 9.6"]]></title><description><![CDATA[
<p>> Upload a package to PyPI or Node.js that emits specially crafted console output as part of its installer.<p>If someone runs my installer without checking the contents, why would I need UTF-8 bugs to get code executed?<p>(Not meant to downplay this bug, but the example made me wonder...)</p>
]]></description><pubDate>Sat, 20 Mar 2021 18:31:07 +0000</pubDate><link>https://news.ycombinator.com/item?id=26524997</link><dc:creator>syzzer</dc:creator><comments>https://news.ycombinator.com/item?id=26524997</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=26524997</guid></item><item><title><![CDATA[New comment by syzzer in "OpenSSL Security Advisory"]]></title><description><![CDATA[
<p>Note that this is specifically OpenVPN on Windows, since the Windows installers ship with their own openssl dll (and as already said by the other commenter, a new installer was made available around the time of your post). All other platforms simply use the system library.</p>
]]></description><pubDate>Thu, 09 Jul 2015 20:06:09 +0000</pubDate><link>https://news.ycombinator.com/item?id=9860337</link><dc:creator>syzzer</dc:creator><comments>https://news.ycombinator.com/item?id=9860337</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=9860337</guid></item><item><title><![CDATA[New comment by syzzer in "Logjam TLS attack"]]></title><description><![CDATA[
<p>Thanks for elaborating.<p>The 'other side' are the people currently working on the negotiated-ffdhe draft (which I assume are bright people too). The draft was last updated a week ago (12 May 2015), so their considerations must be quite recent.<p>I'm just trying to get a sense of pros and cons. Iirc, generating own groups has its problems too. For example, the Triple Handshake attack (<a href="https://www.secure-resumption.com/" rel="nofollow">https://www.secure-resumption.com/</a>) could break TLS because implementations did not properly validate DH params. Allowing only some (set of) pre-defined (known good) params would have stopped <i>that</i> attack.<p>To be clear, I'm certainly not arguing for or against using common groups. Just trying to get a complete picture. (And yes, based on current information I think too that using unique groups is the right approach.)</p>
]]></description><pubDate>Wed, 20 May 2015 10:57:44 +0000</pubDate><link>https://news.ycombinator.com/item?id=9575507</link><dc:creator>syzzer</dc:creator><comments>https://news.ycombinator.com/item?id=9575507</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=9575507</guid></item><item><title><![CDATA[New comment by syzzer in "Logjam TLS attack"]]></title><description><![CDATA[
<p>I strongly believe in 'Audi alteram partem', and like to understand rather than believe. Hence my question.<p>For all I know, a few extra bits parameter length can make the NFS just as infeasible as generating own parameters.<p>Edit: re-reading my earlier comment I understand your reply better. I've expanded my question to 'even with larger group sizes', as it indeed is clear that it <i>is</i> a problem with smaller groups.</p>
]]></description><pubDate>Wed, 20 May 2015 08:53:55 +0000</pubDate><link>https://news.ycombinator.com/item?id=9575166</link><dc:creator>syzzer</dc:creator><comments>https://news.ycombinator.com/item?id=9575166</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=9575166</guid></item><item><title><![CDATA[New comment by syzzer in "Logjam TLS attack"]]></title><description><![CDATA[
<p>>  It's not particularly surprising to the IETF TLS Working Group either, which is at least partially why <a href="https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe.." rel="nofollow">https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe...</a>. exists.<p>This draft /does/ encourages use of larger keys, but also encourages the use of common parameter groups. The weakdh.org site mentions the use of common groups is a reason for this attack to be feasible. It also advises sysadmins to generate their own parameters. To me, that makes using common groups sound like a bad move.<p>The problem is, I lack proper knowledge to assess whether using common groups really is a bad move, even when using larger group sizes... Anyone here who can?</p>
]]></description><pubDate>Wed, 20 May 2015 08:28:28 +0000</pubDate><link>https://news.ycombinator.com/item?id=9575092</link><dc:creator>syzzer</dc:creator><comments>https://news.ycombinator.com/item?id=9575092</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=9575092</guid></item><item><title><![CDATA[New comment by syzzer in "OpenSSL Security Advisory"]]></title><description><![CDATA[
<p>You don't need another layer of encryption, just another layer of authentication protects you from attacks that require an active mitm adversary (as basically all attacks on TLS do).<p>OpenVPN has offered such an option for a long time:
<a href="https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-auth" rel="nofollow">https://community.openvpn.net/openvpn/wiki/Hardening#Useof--...</a><p>This wraps just the TLS control channel, which has low traffic and thus results in a small overhead. The data channel is separated from TLS in OpenVPN, which is why TLS-auth does not add overhead to the actual network packet encapsulation. TLS-auth is a neat feature and everybody should use it.</p>
]]></description><pubDate>Thu, 05 Jun 2014 14:44:53 +0000</pubDate><link>https://news.ycombinator.com/item?id=7852198</link><dc:creator>syzzer</dc:creator><comments>https://news.ycombinator.com/item?id=7852198</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=7852198</guid></item><item><title><![CDATA[New comment by syzzer in "Successful private key extraction from OpenVPN using Heartbleed"]]></title><description><![CDATA[
<p>You should do that for all your vulnerable peers (i.e. clients too), and restart the daemon to make it load the updated library. Then generate new keys for all of them.<p>While there are vulnerable clients out there, you should consider your (vpn) network compromised.</p>
]]></description><pubDate>Wed, 16 Apr 2014 19:07:33 +0000</pubDate><link>https://news.ycombinator.com/item?id=7599837</link><dc:creator>syzzer</dc:creator><comments>https://news.ycombinator.com/item?id=7599837</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=7599837</guid></item><item><title><![CDATA[New comment by syzzer in "The Heartbleed Bug"]]></title><description><![CDATA[
<p>Yes, this has been introduced in the original heartbeat extension commit (01-01-2012):<p><a href="http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=bd6941cfaa31ee8a3f8661cb98227a5cbcc0f9f3" rel="nofollow">http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=bd69...</a></p>
]]></description><pubDate>Mon, 07 Apr 2014 22:43:36 +0000</pubDate><link>https://news.ycombinator.com/item?id=7550145</link><dc:creator>syzzer</dc:creator><comments>https://news.ycombinator.com/item?id=7550145</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=7550145</guid></item></channel></rss>