Re: [Openvpn-devel] Summary of the community meeting (Wed, 19th Dec 2018)

2018-12-19 Thread Antonio Quartulli 
Hi,

On 20/12/2018 02:00, Jan Just Keijser wrote:
> No, it is NOT possible to specify a new "auth" parameter, e.g. "auth
> sha512" as this would break many things, including tls-crypt.

Little note here: tls-auth would "break" because it learns the algorithm
to use from the "auth" parameter, but tls-crypt(-v2) statically uses
AES-256-CTR/SHA256, so that can't be changed.

Cheers,


-- 
Antonio Quartulli



signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Summary of the community meeting (Wed, 19th Dec 2018)

2018-12-19 Thread Jan Just Keijser 

Hi list,

as a follow-up to the discussion we had in the community meeting:

(13:38:08) dazo: janjust: if you get a chance to verify whether using 
non-ncp-listed cipher works with ccd, that's a good detail to know


the answer is: yes and no ;)

Yes, it is possible to specify a *NEW* list of ncp ciphers in a CCD 
file, overruling what is specified globally, provided that this same 
"new" list of NCP ciphers is specified on the client side. This means 
that the maximum *cipher* length is dependent on whatever is specified 
in a CCD file. However, most ciphers used nowadays are 256 bits (32 
bytes) in length anyways, so the impact on the maximum cipher length is 
quite small.


No, it is NOT possible to specify a new "auth" parameter, e.g. "auth 
sha512" as this would break many things, including tls-crypt. Thus, 
there is no need to do a "worst case" calculation inside 
"crypto_max_overhead()" to determine the biggest HMAC value possible. 
Whatever is specified globally is as big as it will get.


My current conclusion is that the crypto_max_overhead function needs a 
significant rewrite. The current code is:


 755 size_t
 756 crypto_max_overhead(void)
 757 {
 758 return packet_id_size(true) + OPENVPN_MAX_IV_LENGTH
 759    +OPENVPN_MAX_CIPHER_BLOCK_SIZE
 760    +max_int(OPENVPN_MAX_HMAC_SIZE, OPENVPN_AEAD_TAG_LENGTH);
 761 }

Question:   is the packet_id part of the crypto?  or is packet_id used, 
regardless of whether crypto is used at all? If so, then the 
packet_id_size needs to be removed from this function.


I'd be in favor of updating the above code to
- take into account the space allocated for the default/globally 
specified crypto; if the default/globally specified crypto is at the 
maximum value (currently 256 bits) then don't bother calculating a worst 
case value
- determine *at runtime* the worst case scenario for the crypto 
overhead, possibly by checking if client-config-dir and/or 
client-connect script or plugin is specified. If one of those IS 
specified, then allocate more space, otherwise use the largest cipher 
length from the first step.
- figure out whether the OPENVPN_MAX_IV_LENGTH is needed whenever an 
AEAD cipher is used - in which case the overhead needs to be calculated 
differently.


I hope others like syzzer can comment on my proposal :)

share and enjoy,

JJK



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Summary of the community meeting (Wed, 19th Dec 2018)

2018-12-19 Thread Samuli Seppänen 
Hi,

Here's the summary of the IRC meeting.

---

COMMUNITY MEETING

Place: #openvpn-meeting on irc.freenode.net
Date: Wednesday 19th December 2018
Time: 11:30 CET (10:30 UTC)

Planned meeting topics for this meeting were here:



The next meeting has not been scheduled yet.

Your local meeting time is easy to check from services such as



SUMMARY

cron2, dazo, janjust, mattock, ordex, plaisthos, rozmansi and syzzer
participated in this meeting.

--

Mattock has almost finished the work on a Vagrant-based build VM that
will use sbuild_wrapper to produce Debian and Ubuntu packages. This
enables anyone to produce "official" OpenVPN Debian packages without the
effort of setting up the build environment manually.

--

Mattock requested review for a couple of openvpn-vagrant PRs. More are
coming up to openvpn-vagrant as well as to sbuild_wrapper.

--

Discussed tap-windows6 HLK testing / WHQL certification. Stephen has
made good progress in resolving the issues in tap-windows6 that prevent
it from passing the HLK tests. It will take a bit more time to resolve
them, but we're getting there. The person who bragged about having WHQL
certified tap-windows6 has not responded to Stephen/us yet.

--

Discussed Windows VPN API. It will not be a replacement for tap-windows6
driver in the near future for multiple reasons:

- It is immature and buggy
- It performs (even) worse than tap-windows6
- It is client-side only (people do run OpenVPN servers on Windows)
- Microsoft tends to break it accidentally

--

Discussed MSI packaging which is almost ready now: mostly end-user
documentation is missing. Mattock is nearing the point where he can
start testing the whole build/packaging process. It was agreed that we
need thorough testing of the MSI packages. The participants of the
meeting seemed to collectively have a good selections of Windows
versions to test it on.

Test installers by rozmansi are available here:

https://github.com/rozmansi/openvpn/releases

The current ones are a bit outdated, so please wait until tomorrow (20th
Dec) before you try them out.

--

The rate-limiting patches would require review/feedback from syzzer.

--

No progress since last week on the VLAN v2 patchset.

--

Ordex will try to send the "transport-api" patchset to the list this
week or the next. The transport API will allow, for example, writing
obfuscation plugins. The code was sponsored by Google's Jigsaw project
and the code was good, but some cleanups by ordex are required to clean
up the commit history.

--

Agreed that we need to look into MTU handling and deprecation of
--fragment in OpenVPN 2.5 in more detail before making any decisions.
For example, right now 2.4/2.5 code base subtracts too much from the
server-side MTU when compensating for NCP, reducing in performance
reduction of ~10%. Details are available in the chatlog.

Previous discussion about this is here:

https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17966.html

--

Full chatlog attached.



(12:26:28) L'argomento di #openvpn-meeting è: Next meeting on 24/Oct/2018 at 
11:30CEST. Agenda at 
https://community.openvpn.net/openvpn/wiki/Topics-2018-12-12
(12:26:28) L'argomento per #openvpn-meeting è stato impostato da 
dazo!~freenode@openvpn/corp/developer/dazo a 12:37:08 su 12/12/2018
(12:26:34) mattock: hi
(12:30:26) rozmansi [sid334387@gateway/web/irccloud.com/x-okfxlucegyhkabad] è 
entrato nella stanza.
(12:30:34) rozmansi: hi
(12:31:01) mattock: hi rozmansi!
(12:31:10) syzzer: hi :)
(12:31:32) mattock: hi
(12:32:07) cron2: re
(12:32:18) cron2: sorry for being late
(12:32:24) cron2: had a meeting :)
(12:32:25) mattock: no problem, only two minutes
(12:32:44) mattock: anyone else joining today?
(12:34:51) janjust [~janjust@openvpn/community/support/janjust] è entrato nella 
stanza.
(12:35:16) cron2: mornin' janjust :)
(12:35:21) janjust: morning folks
(12:35:30) janjust: it's been a while :)
(12:35:36) rozmansi: morning
(12:36:07) janjust: has the meeting started yet?
(12:36:31) cron2: mattock1: please start :)
(12:36:35) plaisthos: hi
(12:36:42) dazo: Hey!
(12:36:53) mattock: let's go
(12:37:13) mattock: anything to add to the topic list? 
https://community.openvpn.net/openvpn/wiki/Topics-2018-12-19
(12:37:15) vpnHelper: Title: Topics-2018-12-19 – OpenVPN Community (at 
community.openvpn.net)
(12:37:33) janjust: I am here to talk about fragment+mtu things ...
(12:37:58) cron2: oh, lots of new items on the agenda
(12:37:58) mattock: ok
(12:38:14) mattock: I'll cover #1 quickly
(12:38:45) dazo: Since janjust is here just for the mtu/fragment stuff ... lets 
squeeze that in afterwards
(12:38:55) mattock: so I have a Vagrant VM almost ready sets up sbuild_wrapper 
and the build schroot and allows Joe Random to build the Debian/Ubuntu packages
(12:39:09) mattock: includes patches to openvpn-vagrant and sbuild_wrapper
(12:39:11) mattock: that's it