Re: [Openvpn-devel] Native OS X tunnels
Just a recommendation, but I wouldn't necessarily consider the two proposals alternatives. The only interesting thing going on here is an implementation of open_tun that creates utun devices. The rest is just wiring. Even open_tun isn't really subtle or complex, merely a bit arcane. I suspect the key decisions are how aggressive to make the migration path and how discoverable to make the configuration--if any--at which point there is now more than enough raw material from which to assemble the feature. Thanks On Jun 17, 2013, at 10:39 AM, Gert Doering wrote: > Hi, > > On Mon, Jun 17, 2013 at 11:33:54AM -0400, Jonathan K. Bullard wrote: >> I have a slight preference forArne's patch, which doesn't introduce yet >> another new OpenVPN option. > > Without having compared the code itself, I second that argument. No more > super-special-case options (which depend on #ifdef TARGET_XYZ), please. > > Now it might be a good idea to find time to actually read both patches > before Thursday and have a more educated opinion :-) *put on TODO list* > > gert > > -- > USENET is *not* the non-clickable part of WWW! > //www.muc.de/~gert/ > Gert Doering - Munich, Germany g...@greenie.muc.de > fax: +49-89-35655025g...@net.informatik.tu-muenchen.de > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev___ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Openvpn-devel] Adding support for AEAD cipher modes (AES-GCM, et al.)
Hi, On Mon, Jun 17, 2013 at 09:32:35AM +0200, Joachim Schipper wrote: > Again, thanks for the patch! I'm no contributor, but I do think it's really > cool. By helping review crypto related code, you are contributing in quite important ways :-) "Contributor" does not require "write code" or "hanging around on IRC" - helping track down bugs, reviewing code, testing on obscure platforms, etc. is all quite relevant contribution... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpPo7cEZXw3Q.pgp Description: PGP signature
Re: [Openvpn-devel] Native OS X tunnels
Hi, On Mon, Jun 17, 2013 at 11:33:54AM -0400, Jonathan K. Bullard wrote: > I have a slight preference forArne's patch, which doesn't introduce yet > another new OpenVPN option. Without having compared the code itself, I second that argument. No more super-special-case options (which depend on #ifdef TARGET_XYZ), please. Now it might be a good idea to find time to actually read both patches before Thursday and have a more educated opinion :-) *put on TODO list* gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpgPqO1myOFr.pgp Description: PGP signature
Re: [Openvpn-devel] Fix for CVE-2013-2061 breaks multihome?
On Mon, Jun 17, 2013 at 05:36:23PM +0200, Gert Doering wrote: > Hi, > > On Mon, Jun 17, 2013 at 04:36:44PM +0200, Alberto Gonzalez Iniesta wrote: > > Seems like "cmsg_len" went nuts... > > Seems your compiler grew too much smarts and optimized that bug to death :-) > > > Again, only happens with multihome, if that helps... > > That code path is only used for multihome. Bugfix is here (if it's indeed > *that* problem): > Thanks a log Gert. Yes, applying the patch solved the problem. Cheers, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55
Re: [Openvpn-devel] Fix for CVE-2013-2061 breaks multihome?
Hi, On Mon, Jun 17, 2013 at 04:36:44PM +0200, Alberto Gonzalez Iniesta wrote: > Seems like "cmsg_len" went nuts... Seems your compiler grew too much smarts and optimized that bug to death :-) > Again, only happens with multihome, if that helps... That code path is only used for multihome. Bugfix is here (if it's indeed *that* problem): commit 8c431f960357d776cfd0961192214ad1b0942bfb Author: Gert Doering List-Post: openvpn-devel@lists.sourceforge.net Date: Thu May 30 13:31:24 2013 +0200 Fix problem with UDP tunneling due to mishandled pktinfo structures. In link_socket_write_udp_posix_sendmsg(), pktinfo structures for ipv4 and ipv6 are going out of scope before actually calling sendmsg(), so depending on compiler optimization, garbage is passed to sendmsg() - fix by using "union openvpn_pktinfo" and having that in scope all the time. Problem reported and patch provided by "danta" in trac#297 Signed-off-by: Gert Doering Acked-by: Gert Doering Acked-by: Arne Schwabe URL: https://community.openvpn.net/openvpn/ticket/297 Message-ID: <20130530184427.gp20...@greenie.muc.de> URL: http://article.gmane.org/gmane.network.openvpn.devel/7629 gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpma8PkvLEkp.pgp Description: PGP signature
Re: [Openvpn-devel] Native OS X tunnels
On Sun, Jun 16, 2013 at 5:14 PM, Arne Schwabe wrote: > > I think using utun as default at least for -master and 2.4rc candidates is > a good way to get the feature tested. I hope there is time in the next > OpenVPN developer IRC meeting to decide if my or your patch should be > included. I won't be in the IRC chat, so here are my comments on Arne's patch vs. Peter's patch from a feature perspective: The behavior difference between the two patches seems to be that Arne's patch defaults to using utun, whereas Peter's patch defaults to tun. >From what I understand, utun seems to work and even works in some situations where the standard tuntaposx tun doesn't and is the Apple-supported standard. So I think users should transition to using it. To help them along, I think defaulting to utun is a good idea. I intend to add 2.4rc builds to Tunnelblick when they are available and to support utun on 10.7+ systems. (Tunnelblick lets users choose which OpenVPN version they use; usually I allow two or three choices, so it's easy to add new versions of OpenVPN for testing.) Whichever patch is included, I think Tunnelblick's default will be to use utun, and give the user a way to override that and use tun. It looks like I can easily use tun with Arne's patch by specifying "--dev-type tun" to revert to using tun, and easily use utun with Peter's patch by specifying "--dev-impl-osx utun". I have a slight preference forArne's patch, which doesn't introduce yet another new OpenVPN option. I am not expressing an opinion on the code in the patches, but only on their default behaviors.
Re: [Openvpn-devel] Fix for CVE-2013-2061 breaks multihome?
On Mon, Jun 17, 2013 at 04:05:18PM +0200, Alberto Gonzalez Iniesta wrote:
> On Mon, Jun 17, 2013 at 01:51:13PM +0200, Gert Doering wrote:
> > Hi,
> >
> > On Mon, Jun 17, 2013 at 01:00:03PM +0200, Alberto Gonzalez Iniesta wrote:
> > > I applied the fix for CVE-2013-2061 [0] to Debian's stable version of
> > > openvpn (2.2.1) [1]. When the new package was sent to the mirrors I got
> > > a couple of reports of broken VPNs [2]. After some testing I think the
> > > problem arises with the use of "multihome" option. The server daemon
> > > starts to log lots of these:
> > > Jun 17 12:43:52 srv ovpn-srv[31073]: write UDPv4 []: Invalid argument
> > > (code=22)
> > > Jun 17 12:43:53 srv ovpn-srv[31073]: write UDPv4 []: Invalid argument
> > > (code=22)
> > >
> > > If the "multihome" option is removed, the VPN comes back to live.
> > >
> > > Could a patch to fix this be made or should we go back to 2.2.1 without
> > > the patch to fix CVE-2013-2061?
> >
> > This patch is most definitely not affecting multihome. If you look at
> > the patch, there is nothing in there that could affect external behaviour
> > (except remove the timing variance).
> >
>
> Thanks Gert,
>
> I compiled the package without the patch now, and get the same (bogus)
> result. Somethigng must have changed in the build environment that
> breaks this. Will investigate further.
Does this strace output help?
>From working build:
sendmsg(6, {msg_name(16)={sa_family=AF_INET, sin_port=htons(33497),
sin_addr=inet_addr("62.82.17.220")},
msg_iov(1)=[{"h\22\260\274\377\244\300\234G\5,\256\376d\5+
\274\264V\260\20\201\tNO\202\271\354\351E}\322"...,
124}], msg_controllen=28, {cmsg_len=28, cmsg_level=SOL_IP, cmsg_type=, ...},
msg_flags=0}, 0) = 124
poll([{fd=6, events=POLLIN|POLLPRI}, {fd=7, events=POLLIN|POLLPRI}], 2, 4037) =
1 ([{fd=6, revents=POLLIN}])
>From failing build:
sendmsg(6, {msg_name(16)={sa_family=AF_INET, sin_port=htons(33497),
sin_addr=inet_addr("62.82.17.220")},
msg_iov(1)=[{">]\253^\16\330\226\202\3\350\31\31tC\247\352\244\10\0-
(\363\377\364\2077\360h\215\333\216{"..., 124}],
msg_controllen=28, {cmsg_len=662516248, cmsg_level=SOL_IP, cmsg_type=, ...},
msg_flags=0}, 0) = -1 EINVAL (Invalid argument)
recvmsg(6, 0x7fff5686b060, MSG_ERRQUEUE) = -1 EAGAIN (Resource temporarily
unavailable)
Seems like "cmsg_len" went nuts...
Again, only happens with multihome, if that helps...
--
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
agi@(inittab.org|debian.org)| en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com
Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55
Re: [Openvpn-devel] Fix for CVE-2013-2061 breaks multihome?
On Mon, Jun 17, 2013 at 01:51:13PM +0200, Gert Doering wrote: > Hi, > > On Mon, Jun 17, 2013 at 01:00:03PM +0200, Alberto Gonzalez Iniesta wrote: > > I applied the fix for CVE-2013-2061 [0] to Debian's stable version of > > openvpn (2.2.1) [1]. When the new package was sent to the mirrors I got > > a couple of reports of broken VPNs [2]. After some testing I think the > > problem arises with the use of "multihome" option. The server daemon > > starts to log lots of these: > > Jun 17 12:43:52 srv ovpn-srv[31073]: write UDPv4 []: Invalid argument > > (code=22) > > Jun 17 12:43:53 srv ovpn-srv[31073]: write UDPv4 []: Invalid argument > > (code=22) > > > > If the "multihome" option is removed, the VPN comes back to live. > > > > Could a patch to fix this be made or should we go back to 2.2.1 without > > the patch to fix CVE-2013-2061? > > This patch is most definitely not affecting multihome. If you look at > the patch, there is nothing in there that could affect external behaviour > (except remove the timing variance). > Thanks Gert, I compiled the package without the patch now, and get the same (bogus) result. Somethigng must have changed in the build environment that breaks this. Will investigate further. -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55
Re: [Openvpn-devel] Fix for CVE-2013-2061 breaks multihome?
Hi, On Mon, Jun 17, 2013 at 01:00:03PM +0200, Alberto Gonzalez Iniesta wrote: > I applied the fix for CVE-2013-2061 [0] to Debian's stable version of > openvpn (2.2.1) [1]. When the new package was sent to the mirrors I got > a couple of reports of broken VPNs [2]. After some testing I think the > problem arises with the use of "multihome" option. The server daemon > starts to log lots of these: > Jun 17 12:43:52 srv ovpn-srv[31073]: write UDPv4 []: Invalid argument > (code=22) > Jun 17 12:43:53 srv ovpn-srv[31073]: write UDPv4 []: Invalid argument > (code=22) > > If the "multihome" option is removed, the VPN comes back to live. > > Could a patch to fix this be made or should we go back to 2.2.1 without > the patch to fix CVE-2013-2061? This patch is most definitely not affecting multihome. If you look at the patch, there is nothing in there that could affect external behaviour (except remove the timing variance). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpVSMQpuGyFl.pgp Description: PGP signature
[Openvpn-devel] Fix for CVE-2013-2061 breaks multihome?
Hi, I applied the fix for CVE-2013-2061 [0] to Debian's stable version of openvpn (2.2.1) [1]. When the new package was sent to the mirrors I got a couple of reports of broken VPNs [2]. After some testing I think the problem arises with the use of "multihome" option. The server daemon starts to log lots of these: Jun 17 12:43:52 srv ovpn-srv[31073]: write UDPv4 []: Invalid argument (code=22) Jun 17 12:43:53 srv ovpn-srv[31073]: write UDPv4 []: Invalid argument (code=22) If the "multihome" option is removed, the VPN comes back to live. Could a patch to fix this be made or should we go back to 2.2.1 without the patch to fix CVE-2013-2061? Thanks, Alberto [0] https://github.com/OpenVPN/openvpn/commit/11d21349a4e7e38a025849479b36ace7c2eec2ee [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707329 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712414 -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55
Re: [Openvpn-devel] OpenVPN Versioning
On 06/14/2013 09:53 PM, James Yonan wrote:
> To get the adaptive versioning behavior in OpenSSL, you have to use
> SSLv23_server_method() or SSLv23_client_method() and then explicitly
> disable the versions you don't want to consider, i.e. SSL_OP_NO_SSLv2,
> SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1, SSL_OP_NO_TLSv1_1, etc.
>
Wow, so SSLv23_{client,server}_method() is the 'wildcard' you need to
dynamically negotiate the version. Yet it sounds like something
completely broken that should be avoided at all cost. OpenSSL keeps
amazing me.
>> Does the change to key_state_ssl_init() do anything?
>
> I had to add ssl_flags (containing tls-version-min parameter) to
> key_state_ssl_init because that seems like the most appropriate place to
> configure tls-version-min for PolarSSL.
>
> For OpenSSL, tls_ctx_set_options is the right place to configure
> tls-version-min.
>
The ssl_flags are already available through the tls session that is
passed as the fourth parameter. To make this a bit more clear, commit
b97e2c3 changed the type of session to struct tls session* (see
https://github.com/OpenVPN/openvpn/commit/b97e2c3c90afdbb1a24bc1357ec6b94d626defcd).
-Steffan
Re: [Openvpn-devel] Adding support for AEAD cipher modes (AES-GCM, et al.)
> -Original Message- > From: Kenny Root [mailto:ke...@the-b.org] > Sent: dinsdag 4 juni 2013 2:15 > To: openvpn-devel@lists.sourceforge.net > Subject: [Openvpn-devel] Adding support for AEAD cipher modes > (AES-GCM, et al.) > > I wrote a patch to add AEAD cipher modes to OpenVPN. This is one of > NIST's recommended modes and newer Intel chips supporting the AES-NI > (with PCLMULQDQ) have excellent support for acceleration in this mode. > I posted the initial version at > https://community.openvpn.net/openvpn/ticket/301 and that ticket has > some of the performance numbers on an Ivy Bridge class chip. > > It also doesn't appear PolarSSL has added AES-GCM to their main crypto > API yet. > > (You can also comment at Github at > https://github.com/kruton/openvpn/commit/a8c6701c8b47429c32da5c01f4398 > f > 9e0b293c01) Cool to see support for GCM in the data channel! PolarSSL does support GCM (since 1.2, see include/polarssl/gcm.h), and indeed OpenVPN-NL exclusively uses a GCM SSL ciphersuite in the control channel. However, it would be very neat to also have it in the data channel, so I looked at your patch with great interest. It's really neat, but I do have some comments. I don't really see the benefit of adding CCM support; I'm not aware of any new protocol using it, since GCM is generally faster/nicer/more common, and - on recent Intel chips - benefits from hardware support (GCLMULQDQ). That said, it's not hard, so... XTS seems rather unsuited for this application; it's an unauthenticated tweakable block cipher used for disk encryption. The fact that it uses the same API as GCM/CCM is yet another instance of OpenSSL perfectly aligning a gun with your foot. The prng_bytes() on src/openvpn/crypto.c:144 seems odd in various ways. I'll continue reviewing tonight and tomorrow morning, and I'll take a good look at this chunk of code then. (Sorry for the slow review; life and spotty internet in the train got in the way.) I don't understand src/openvpn/crypto.c:194 either, but I'll take another look tonight. Some further minor comments: src/openvpn/crypto.c:311: MAX_HMAC_KEY_LENGTH is a rather strange name for the length of a variable holding the authentication tag. src/openvpn/crypto.c 322: whitespace error src/openvpn/crypto.c 430: #ifndef ALLOW_NON_CBC_CIPHERS, we still allow AEAD? That seems odd. Src/openvpn/crypto_backend.h:271: "message authentication code". In general, neither the function name nor the doxygen makes it obvious that this function is valid only for AEAD modes. Again, thanks for the patch! I'm no contributor, but I do think it's really cool. Joachim smime.p7s Description: S/MIME cryptographic signature
