Commit c4f02d

2025-01-29 08:37:37 Samuli Seppänen: Clean up after switching case-sensitivity on plus import more Signed-off-by: Samuli Seppänen <samuli.seppanen@gmail.com>

home.md .. Home.md
meetings.md .. Meetings.md
meetings/2010/2010-04-22.md .. Meetings/2010/2010-04-22.md
meetings/2010/2010-04-29.md .. Meetings/2010/2010-04-29.md
meetings/2010/2010-05-06.md .. Meetings/2010/2010-05-06.md
meetings/2010/2010-05-13.md .. Meetings/2010/2010-05-13.md
meetings/2010/2010-05-20.md .. Meetings/2010/2010-05-20.md
meetings/2010/2010-05-27.md .. Meetings/2010/2010-05-27.md
meetings/2010/2010-06-03.md .. Meetings/2010/2010-06-03.md
meetings/2010/2010-06-10.md .. Meetings/2010/2010-06-10.md
meetings/2010/2010-06-17.md .. Meetings/2010/2010-06-17.md
meetings/2010/2010-07-01.md .. Meetings/2010/2010-07-01.md
meetings/2010/2010-07-08.md .. Meetings/2010/2010-07-08.md
meetings/2010/2010-07-15.md .. Meetings/2010/2010-07-15.md
meetings/2010/2010-07-22.md .. Meetings/2010/2010-07-22.md
meetings/2010/2010-07-29.md .. Meetings/2010/2010-07-29.md
meetings/2010/2010-08-05.md .. Meetings/2010/2010-08-05.md
meetings/2010/2010-08-12.md .. Meetings/2010/2010-08-12.md
meetings/2010/2010-08-19.md .. Meetings/2010/2010-08-19.md
meetings/2010/2010-08-26.md .. Meetings/2010/2010-08-26.md
meetings/2010/2010-09-02.md .. Meetings/2010/2010-09-02.md
meetings/2010/2010-09-16.md .. Meetings/2010/2010-09-16.md
meetings/2010/2010-09-23.md .. Meetings/2010/2010-09-23.md
meetings/2010/2010-10-14.md .. Meetings/2010/2010-10-14.md
meetings/2010/2010-10-21.md .. Meetings/2010/2010-10-21.md
meetings/2010/2010-11-18.md .. Meetings/2010/2010-11-18.md
meetings/2010/2010-11-25.md .. Meetings/2010/2010-11-25.md
meetings/2010/2010-12-02.md .. Meetings/2010/2010-12-02.md
meetings/2010/2010-12-09.md .. Meetings/2010/2010-12-09.md
meetings/2010/2010-12-16.md .. Meetings/2010/2010-12-16.md
meetings/2011/2011-01-06.md .. Meetings/2011/2011-01-06.md
meetings/2011/2011-01-13.md .. Meetings/2011/2011-01-13.md
meetings/2011/2011-02-10.md .. Meetings/2011/2011-02-10.md
meetings/2011/2011-02-17.md .. Meetings/2011/2011-02-17.md
meetings/2011/2011-03-24.md .. Meetings/2011/2011-03-24.md
meetings/2011/2011-04-07.md .. Meetings/2011/2011-04-07.md
meetings/2011/2011-04-14.md .. Meetings/2011/2011-04-14.md
meetings/2011/2011-04-28.md .. Meetings/2011/2011-04-28.md
meetings/2011/2011-05-19.md .. Meetings/2011/2011-05-19.md
meetings/2011/2011-06-09.md .. Meetings/2011/2011-06-09.md
meetings/2011/2011-06-16.md .. Meetings/2011/2011-06-16.md
meetings/2011/2011-06-30.md .. Meetings/2011/2011-06-30.md
meetings/2011/2011-07-07.md .. Meetings/2011/2011-07-07.md
meetings/2011/2011-07-14.md .. Meetings/2011/2011-07-14.md
meetings/2011/2011-07-21.md .. Meetings/2011/2011-07-21.md
meetings/2011/2011-07-26.md .. Meetings/2011/2011-07-26.md
meetings/2011/2011-07-28.md .. Meetings/2011/2011-07-28.md
meetings/2011/2011-08-03.md .. Meetings/2011/2011-08-03.md
meetings/2011/2011-08-11.md .. Meetings/2011/2011-08-11.md
meetings/2011/2011-08-18.md .. Meetings/2011/2011-08-18.md
meetings/2011/2011-08-25.md .. Meetings/2011/2011-08-25.md
meetings/2011/2011-09-01.md .. Meetings/2011/2011-09-01.md
meetings/2011/2011-09-08.md .. Meetings/2011/2011-09-08.md
meetings/2011/2011-09-14.md .. Meetings/2011/2011-09-14.md
meetings/2011/2011-09-15.md .. Meetings/2011/2011-09-15.md
meetings/2011/2011-09-29.md .. Meetings/2011/2011-09-29.md
meetings/2011/2011-10-06.md .. Meetings/2011/2011-10-06.md
meetings/2011/2011-10-20.md .. Meetings/2011/2011-10-20.md
meetings/2011/2011-11-24.md .. Meetings/2011/2011-11-24.md
meetings/2011/2011-12-08.md .. Meetings/2011/2011-12-08.md
meetings/2012/2012-01-19.md .. Meetings/2012/2012-01-19.md
meetings/2012/2012-03-15.md .. Meetings/2012/2012-03-15.md
meetings/2012/2012-04-26.md .. Meetings/2012/2012-04-26.md
meetings/2012/2012-05-31.md .. Meetings/2012/2012-05-31.md
meetings/2012/2012-06-21.md .. Meetings/2012/2012-06-21.md
meetings/2012/2012-11-29.md .. Meetings/2012/2012-11-29.md
meetings/2013/2013-04-18.md .. Meetings/2013/2013-04-18.md
meetings/2013/2013-04-25.md .. Meetings/2013/2013-04-25.md
meetings/2013/2013-05-09.md .. Meetings/2013/2013-05-09.md
meetings/2013/2013-05-23.md .. Meetings/2013/2013-05-23.md
meetings/2013/2013-06-20.md .. Meetings/2013/2013-06-20.md
meetings/2013/2013-07-11.md .. Meetings/2013/2013-07-11.md
meetings/2013/2013-08-08.md .. Meetings/2013/2013-08-08.md
meetings/2013/2013-08-22.md .. Meetings/2013/2013-08-22.md
meetings/2013/2013-11-16.md .. Meetings/2013/2013-11-16.md
meetings/2013/2013-ProductNamespaces.md .. Meetings/2013/2013-ProductNamespaces.md
meetings/2014/2014-01-09.md .. Meetings/2014/2014-01-09.md
meetings/2014/2014-04-24.md .. Meetings/2014/2014-04-24.md
meetings/2014/2014-10-23.md .. Meetings/2014/2014-10-23.md
meetings/2014/2014-11-24.md .. Meetings/2014/2014-11-24.md
meetings/2014/2014-12-22.md .. Meetings/2014/2014-12-22.md
meetings/2014/2014-12-29.md .. Meetings/2014/2014-12-29.md
meetings/2015/2015-01-12.md .. Meetings/2015/2015-01-12.md
meetings/2015/2015-01-19.md .. Meetings/2015/2015-01-19.md
meetings/2015/2015-02-02.md .. Meetings/2015/2015-02-02.md
meetings/2015/2015-03-30.md .. Meetings/2015/2015-03-30.md
meetings/2015/2015-04-13.md .. Meetings/2015/2015-04-13.md
meetings/2015/2015-04-27.md .. Meetings/2015/2015-04-27.md
meetings/2015/2015-05-04.md .. Meetings/2015/2015-05-04.md
meetings/2015/2015-05-18.md .. Meetings/2015/2015-05-18.md
meetings/2015/2015-06-01.md .. Meetings/2015/2015-06-01.md
meetings/2015/2015-06-15.md .. Meetings/2015/2015-06-15.md
meetings/2015/2015-06-29.md .. Meetings/2015/2015-06-29.md
meetings/2015/2015-07-13.md .. Meetings/2015/2015-07-13.md
meetings/2015/2015-07-27.md .. Meetings/2015/2015-07-27.md
meetings/2015/2015-08-10.md .. Meetings/2015/2015-08-10.md
meetings/2015/2015-08-24.md .. Meetings/2015/2015-08-24.md
meetings/2015/2015-09-07.md .. Meetings/2015/2015-09-07.md
meetings/2015/2015-09-21.md .. Meetings/2015/2015-09-21.md
meetings/2015/2015-10-05.md .. Meetings/2015/2015-10-05.md
meetings/2015/2015-10-26.md .. Meetings/2015/2015-10-26.md
meetings/2015/2015-11-09.md .. Meetings/2015/2015-11-09.md
meetings/2015/2015-11-23.md .. Meetings/2015/2015-11-23.md
meetings/2015/2015-12-14.md .. Meetings/2015/2015-12-14.md
meetings/2015/2015-12-28.md .. Meetings/2015/2015-12-28.md
meetings/2016/2016-01-11.md .. Meetings/2016/2016-01-11.md
meetings/2016/2016-02-01.md .. Meetings/2016/2016-02-01.md
meetings/2016/2016-05-09.md .. Meetings/2016/2016-05-09.md
meetings/2016/2016-05-30.md .. Meetings/2016/2016-05-30.md
meetings/2016/2016-06-13.md .. Meetings/2016/2016-06-13.md
meetings/2016/2016-08-15.md .. Meetings/2016/2016-08-15.md
meetings/2016/2016-08-22.md .. Meetings/2016/2016-08-22.md
meetings/2016/2016-10-10.md .. Meetings/2016/2016-10-10.md
meetings/2016/2016-11-07.md .. Meetings/2016/2016-11-07.md
meetings/2016/2016-11-14.md .. Meetings/2016/2016-11-14.md
meetings/2016/2016-11-23.md .. Meetings/2016/2016-11-23.md
meetings/2016/2016-11-30.md .. Meetings/2016/2016-11-30.md
meetings/2016/2016-12-07.md .. Meetings/2016/2016-12-07.md
meetings/2016/2016-12-14.md .. Meetings/2016/2016-12-14.md
meetings/2016/2016-12-21.md .. Meetings/2016/2016-12-21.md
meetings/2017/2017-01-04.md .. Meetings/2017/2017-01-04.md
meetings/2017/2017-02-22.md .. Meetings/2017/2017-02-22.md
meetings/2017/2017-03-15.md .. Meetings/2017/2017-03-15.md
meetings/2017/2017-09-12.md .. Meetings/2017/2017-09-12.md
meetings/2017/2017-09-20.md .. Meetings/2017/2017-09-20.md
meetings/2017/2017-09-27.md .. Meetings/2017/2017-09-27.md
meetings/2017/2017-10-04.md .. Meetings/2017/2017-10-04.md
meetings/2017/2017-10-11.md .. Meetings/2017/2017-10-11.md
meetings/2017/2017-10-18.md .. Meetings/2017/2017-10-18.md
meetings/2017/2017-10-25.md .. Meetings/2017/2017-10-25.md
meetings/2017/2017-11-01.md .. Meetings/2017/2017-11-01.md
meetings/2017/2017-12-06.md .. Meetings/2017/2017-12-06.md
meetings/2017/2017-12-13.md .. Meetings/2017/2017-12-13.md
meetings/2017/2017-12-20.md .. Meetings/2017/2017-12-20.md
meetings/2018/2018-01-03.md .. Meetings/2018/2018-01-03.md
meetings/2018/2018-01-10.md .. Meetings/2018/2018-01-10.md
meetings/2018/2018-01-17.md .. Meetings/2018/2018-01-17.md
meetings/2018/2018-01-24.md .. Meetings/2018/2018-01-24.md
meetings/2018/2018-01-31.md .. Meetings/2018/2018-01-31.md
meetings/2018/2018-02-21.md .. Meetings/2018/2018-02-21.md
meetings/2018/2018-03-07.md .. Meetings/2018/2018-03-07.md
meetings/2018/2018-03-14.md .. Meetings/2018/2018-03-14.md
meetings/2018/2018-03-21.md .. Meetings/2018/2018-03-21.md
meetings/2018/2018-04-04.md .. Meetings/2018/2018-04-04.md
meetings/2018/2018-04-18.md .. Meetings/2018/2018-04-18.md
meetings/2018/2018-05-02.md .. Meetings/2018/2018-05-02.md
meetings/2018/2018-05-23.md .. Meetings/2018/2018-05-23.md
meetings/2018/2018-05-30.md .. Meetings/2018/2018-05-30.md
meetings/2018/2018-06-06.md .. Meetings/2018/2018-06-06.md
meetings/2018/2018-06-13.md .. Meetings/2018/2018-06-13.md
meetings/2018/2018-07-04.md .. Meetings/2018/2018-07-04.md
meetings/2018/2018-09-19.md .. Meetings/2018/2018-09-19.md
meetings/2018/2018-09-26.md .. Meetings/2018/2018-09-26.md
meetings/2018/2018-10-03.md .. Meetings/2018/2018-10-03.md
meetings/2018/2018-10-10.md .. Meetings/2018/2018-10-10.md
meetings/2018/2018-10-24.md .. Meetings/2018/2018-10-24.md
meetings/2018/2018-11-14.md .. Meetings/2018/2018-11-14.md
meetings/2018/2018-11-28.md .. Meetings/2018/2018-11-28.md
meetings/2018/2018-12-05.md .. Meetings/2018/2018-12-05.md
meetings/2018/2018-12-12.md .. Meetings/2018/2018-12-12.md
meetings/2018/2018-12-19.md .. Meetings/2018/2018-12-19.md
meetings/2019/2019-02-13.md .. Meetings/2019/2019-02-13.md
meetings/2019/2019-03-12.md .. Meetings/2019/2019-03-12.md
meetings/2019/2019-03-20.md .. Meetings/2019/2019-03-20.md
meetings/2019/2019-03-27.md .. Meetings/2019/2019-03-27.md
meetings/2019/2019-04-03.md .. Meetings/2019/2019-04-03.md
meetings/2019/2019-04-11.md .. Meetings/2019/2019-04-11.md
meetings/2019/2019-04-17.md .. Meetings/2019/2019-04-17.md
meetings/2019/2019-04-25.md .. Meetings/2019/2019-04-25.md
meetings/2019/2019-05-01.md .. Meetings/2019/2019-05-01.md
meetings/2019/2019-05-09.md .. Meetings/2019/2019-05-09.md
meetings/2019/2019-05-15.md .. Meetings/2019/2019-05-15.md
meetings/2019/2019-05-23.md .. Meetings/2019/2019-05-23.md
meetings/2019/2019-05-29.md .. Meetings/2019/2019-05-29.md
meetings/2019/2019-06-06.md .. Meetings/2019/2019-06-06.md
meetings/2019/2019-06-12.md .. Meetings/2019/2019-06-12.md
meetings/2019/2019-06-20.md .. Meetings/2019/2019-06-20.md
meetings/2019/2019-06-26.md .. Meetings/2019/2019-06-26.md
meetings/2019/2019-07-04.md .. Meetings/2019/2019-07-04.md
meetings/2019/2019-07-10.md .. Meetings/2019/2019-07-10.md
meetings/2019/2019-07-18.md .. Meetings/2019/2019-07-18.md
meetings/2019/2019-07-24.md .. Meetings/2019/2019-07-24.md
meetings/2019/2019-08-07.md .. Meetings/2019/2019-08-07.md
meetings/2019/2019-08-15.md .. Meetings/2019/2019-08-15.md
meetings/2019/2019-08-21.md .. Meetings/2019/2019-08-21.md
meetings/2019/2019-08-29.md .. Meetings/2019/2019-08-29.md
meetings/2019/2019-09-04.md .. Meetings/2019/2019-09-04.md
meetings/2019/2019-09-12.md .. Meetings/2019/2019-09-12.md
meetings/2019/2019-09-18.md .. Meetings/2019/2019-09-18.md
meetings/2019/2019-09-26.md .. Meetings/2019/2019-09-26.md
meetings/2019/2019-10-02.md .. Meetings/2019/2019-10-02.md
meetings/2019/2019-10-10.md .. Meetings/2019/2019-10-10.md
meetings/2019/2019-10-16.md .. Meetings/2019/2019-10-16.md
meetings/2019/2019-10-24.md .. Meetings/2019/2019-10-24.md
meetings/2019/2019-10-30.md .. Meetings/2019/2019-10-30.md
meetings/2019/2019-11-21.md .. Meetings/2019/2019-11-21.md
meetings/2019/2019-11-27.md .. Meetings/2019/2019-11-27.md
meetings/2019/2019-12-05.md .. Meetings/2019/2019-12-05.md
meetings/2019/2019-12-11.md .. Meetings/2019/2019-12-11.md
meetings/2019/2019-12-19.md .. Meetings/2019/2019-12-19.md
meetings/2020/2020-01-06.md .. Meetings/2020/2020-01-06.md
meetings/2020/2020-01-08.md .. Meetings/2020/2020-01-08.md
meetings/2020/2020-01-16.md .. Meetings/2020/2020-01-16.md
meetings/2020/2020-01-22.md .. Meetings/2020/2020-01-22.md
meetings/2020/2020-01-30.md .. Meetings/2020/2020-01-30.md
meetings/2020/2020-02-05.md .. Meetings/2020/2020-02-05.md
meetings/2020/2020-02-13.md .. Meetings/2020/2020-02-13.md
meetings/2020/2020-02-19.md .. Meetings/2020/2020-02-19.md
meetings/2020/2020-02-27.md .. Meetings/2020/2020-02-27.md
meetings/2020/2020-03-04.md .. Meetings/2020/2020-03-04.md
meetings/2020/2020-03-12.md .. Meetings/2020/2020-03-12.md
meetings/2020/2020-03-18.md .. Meetings/2020/2020-03-18.md
meetings/2020/2020-03-26.md .. Meetings/2020/2020-03-26.md
meetings/2020/2020-04-01.md .. Meetings/2020/2020-04-01.md
meetings/2020/2020-04-09.md .. Meetings/2020/2020-04-09.md
meetings/2020/2020-04-15.md .. Meetings/2020/2020-04-15.md
meetings/2020/2020-04-23.md .. Meetings/2020/2020-04-23.md
meetings/2020/2020-04-29.md .. Meetings/2020/2020-04-29.md
meetings/2020/2020-05-07.md .. Meetings/2020/2020-05-07.md
meetings/2020/2020-05-13.md .. Meetings/2020/2020-05-13.md
meetings/2020/2020-05-21.md .. Meetings/2020/2020-05-21.md
meetings/2020/2020-05-27.md .. Meetings/2020/2020-05-27.md
meetings/2020/2020-06-04.md .. Meetings/2020/2020-06-04.md
meetings/2020/2020-06-10.md .. Meetings/2020/2020-06-10.md
meetings/2020/2020-06-18.md .. Meetings/2020/2020-06-18.md
meetings/2020/2020-06-24.md .. Meetings/2020/2020-06-24.md
meetings/2020/2020-07-02.md .. Meetings/2020/2020-07-02.md
meetings/2020/2020-07-08.md .. Meetings/2020/2020-07-08.md
meetings/2020/2020-07-16.md .. Meetings/2020/2020-07-16.md
meetings/2020/2020-07-22.md .. Meetings/2020/2020-07-22.md
meetings/2020/2020-07-30.md .. Meetings/2020/2020-07-30.md
meetings/2020/2020-08-13.md .. Meetings/2020/2020-08-13.md
meetings/2020/2020-08-19.md .. Meetings/2020/2020-08-19.md
meetings/2020/2020-08-27.md .. Meetings/2020/2020-08-27.md
meetings/2020/2020-09-02.md .. Meetings/2020/2020-09-02.md
meetings/2020/2020-09-10.md .. Meetings/2020/2020-09-10.md
meetings/2020/2020-09-16.md .. Meetings/2020/2020-09-16.md
meetings/2020/2020-09-24.md .. Meetings/2020/2020-09-24.md
meetings/2020/2020-09-30.md .. Meetings/2020/2020-09-30.md
meetings/2020/2020-10-08.md .. Meetings/2020/2020-10-08.md
meetings/2020/2020-10-14.md .. Meetings/2020/2020-10-14.md
meetings/2020/2020-10-22.md .. Meetings/2020/2020-10-22.md
meetings/2020/2020-10-28.md .. Meetings/2020/2020-10-28.md
meetings/2020/2020-11-05.md .. Meetings/2020/2020-11-05.md
meetings/2020/2020-11-11.md .. Meetings/2020/2020-11-11.md
meetings/2020/2020-11-19.md .. Meetings/2020/2020-11-19.md
meetings/2020/2020-11-25.md .. Meetings/2020/2020-11-25.md
meetings/2020/2020-12-03.md .. Meetings/2020/2020-12-03.md
meetings/2020/2020-12-09.md .. Meetings/2020/2020-12-09.md
meetings/2020/2020-12-17.md .. Meetings/2020/2020-12-17.md
meetings/2021/2021-01-06.md .. Meetings/2021/2021-01-06.md
meetings/2021/2021-01-20.md .. Meetings/2021/2021-01-20.md
meetings/2021/2021-01-27.md .. Meetings/2021/2021-01-27.md
meetings/2021/2021-02-03.md .. Meetings/2021/2021-02-03.md
meetings/2021/2021-02-10.md .. Meetings/2021/2021-02-10.md
meetings/2021/2021-02-17.md .. Meetings/2021/2021-02-17.md
meetings/2021/2021-02-24.md .. Meetings/2021/2021-02-24.md
meetings/2021/2021-03-03.md .. Meetings/2021/2021-03-03.md
meetings/2021/2021-03-10.md .. Meetings/2021/2021-03-10.md
meetings/2021/2021-03-24.md .. Meetings/2021/2021-03-24.md
meetings/2021/2021-03-31.md .. Meetings/2021/2021-03-31.md
meetings/2021/2021-04-07.md .. Meetings/2021/2021-04-07.md
meetings/2021/2021-04-14.md .. Meetings/2021/2021-04-14.md
meetings/2021/2021-04-21.md .. Meetings/2021/2021-04-21.md
meetings/2021/2021-04-28.md .. Meetings/2021/2021-04-28.md
meetings/2021/2021-05-05.md .. Meetings/2021/2021-05-05.md
meetings/2021/2021-05-12.md .. Meetings/2021/2021-05-12.md
meetings/2021/2021-05-19.md .. Meetings/2021/2021-05-19.md
meetings/2021/2021-05-26.md .. Meetings/2021/2021-05-26.md
meetings/2021/2021-06-02.md .. Meetings/2021/2021-06-02.md
meetings/2021/2021-06-09.md .. Meetings/2021/2021-06-09.md
meetings/2021/2021-06-16.md .. Meetings/2021/2021-06-16.md
meetings/2021/2021-06-23.md .. Meetings/2021/2021-06-23.md
meetings/2021/2021-06-30.md .. Meetings/2021/2021-06-30.md
meetings/2021/2021-07-07.md .. Meetings/2021/2021-07-07.md
meetings/2021/2021-07-14.md .. Meetings/2021/2021-07-14.md
meetings/2021/2021-07-21.md .. Meetings/2021/2021-07-21.md
meetings/2021/2021-07-28.md .. Meetings/2021/2021-07-28.md
meetings/2021/2021-08-04.md .. Meetings/2021/2021-08-04.md
meetings/2021/2021-08-11.md .. Meetings/2021/2021-08-11.md
meetings/2021/2021-08-18.md .. Meetings/2021/2021-08-18.md
meetings/2021/2021-08-25.md .. Meetings/2021/2021-08-25.md
meetings/2021/2021-09-01.md .. Meetings/2021/2021-09-01.md
meetings/2021/2021-09-08.md .. Meetings/2021/2021-09-08.md
meetings/2021/2021-09-15.md .. Meetings/2021/2021-09-15.md
meetings/2021/2021-09-22.md .. Meetings/2021/2021-09-22.md
meetings/2021/2021-09-29.md .. Meetings/2021/2021-09-29.md
meetings/2021/2021-10-13.md .. Meetings/2021/2021-10-13.md
meetings/2021/2021-10-20.md .. Meetings/2021/2021-10-20.md
meetings/2021/2021-10-27.md .. Meetings/2021/2021-10-27.md
meetings/2021/2021-11-10.md .. Meetings/2021/2021-11-10.md
meetings/2021/2021-11-17.md .. Meetings/2021/2021-11-17.md
meetings/2021/2021-11-24.md .. Meetings/2021/2021-11-24.md
meetings/2021/2021-12-01.md .. Meetings/2021/2021-12-01.md
meetings/2021/2021-12-08.md .. Meetings/2021/2021-12-08.md
meetings/2021/2021-12-15.md .. Meetings/2021/2021-12-15.md
meetings/2021/2021-12-22.md .. Meetings/2021/2021-12-22.md
meetings/2022/2022-01-05.md .. Meetings/2022/2022-01-05.md
meetings/2022/2022-01-12.md .. Meetings/2022/2022-01-12.md
meetings/2022/2022-01-19.md .. Meetings/2022/2022-01-19.md
meetings/2022/2022-01-26.md .. Meetings/2022/2022-01-26.md
meetings/2022/2022-02-02.md .. Meetings/2022/2022-02-02.md
meetings/2022/2022-02-09.md .. Meetings/2022/2022-02-09.md
meetings/2022/2022-02-16.md .. Meetings/2022/2022-02-16.md
meetings/2022/2022-02-23.md .. Meetings/2022/2022-02-23.md
meetings/2022/2022-03-02.md .. Meetings/2022/2022-03-02.md
meetings/2022/2022-03-09.md .. Meetings/2022/2022-03-09.md
meetings/2022/2022-03-16.md .. Meetings/2022/2022-03-16.md
meetings/2022/2022-03-23.md .. Meetings/2022/2022-03-23.md
meetings/2022/2022-03-30.md .. Meetings/2022/2022-03-30.md
meetings/2022/2022-04-06.md .. Meetings/2022/2022-04-06.md
meetings/2022/2022-04-13.md .. Meetings/2022/2022-04-13.md
meetings/2022/2022-04-20.md .. Meetings/2022/2022-04-20.md
meetings/2022/2022-04-27.md .. Meetings/2022/2022-04-27.md
meetings/2022/2022-05-04.md .. Meetings/2022/2022-05-04.md
meetings/2022/2022-05-11.md .. Meetings/2022/2022-05-11.md
meetings/2022/2022-05-18.md .. Meetings/2022/2022-05-18.md
meetings/2022/2022-05-25.md .. Meetings/2022/2022-05-25.md
meetings/2022/2022-06-01.md .. Meetings/2022/2022-06-01.md
meetings/2022/2022-06-08.md .. Meetings/2022/2022-06-08.md
meetings/2022/2022-06-15.md .. Meetings/2022/2022-06-15.md
meetings/2022/2022-06-22.md .. Meetings/2022/2022-06-22.md
meetings/2022/2022-06-29.md .. Meetings/2022/2022-06-29.md
meetings/2022/2022-07-06.md .. Meetings/2022/2022-07-06.md
meetings/2022/2022-07-13.md .. Meetings/2022/2022-07-13.md
meetings/2022/2022-07-20.md .. Meetings/2022/2022-07-20.md
meetings/2022/2022-07-27.md .. Meetings/2022/2022-07-27.md
meetings/2022/2022-08-03.md .. Meetings/2022/2022-08-03.md
meetings/2022/2022-08-10.md .. Meetings/2022/2022-08-10.md
meetings/2022/2022-08-17.md .. Meetings/2022/2022-08-17.md
meetings/2022/2022-08-24.md .. Meetings/2022/2022-08-24.md
meetings/2022/2022-08-31.md .. Meetings/2022/2022-08-31.md
meetings/2022/2022-09-07.md .. Meetings/2022/2022-09-07.md
meetings/2022/2022-09-14.md .. Meetings/2022/2022-09-14.md
meetings/2022/2022-09-21.md .. Meetings/2022/2022-09-21.md
meetings/2022/2022-09-28.md .. Meetings/2022/2022-09-28.md
meetings/2022/2022-10-05.md .. Meetings/2022/2022-10-05.md
meetings/2022/2022-10-12.md .. Meetings/2022/2022-10-12.md
meetings/2022/2022-10-19.md .. Meetings/2022/2022-10-19.md
meetings/2022/2022-10-26.md .. Meetings/2022/2022-10-26.md
meetings/2022/2022-11-09.md .. Meetings/2022/2022-11-09.md
meetings/2022/2022-11-23.md .. Meetings/2022/2022-11-23.md
meetings/2022/2022-11-30.md .. Meetings/2022/2022-11-30.md
meetings/2022/2022-12-07.md .. Meetings/2022/2022-12-07.md
meetings/2022/2022-12-14.md .. Meetings/2022/2022-12-14.md
meetings/2022/2022-12-21.md .. Meetings/2022/2022-12-21.md
meetings/2022/2022-12-28.md .. Meetings/2022/2022-12-28.md
meetings/2023/2023-01-11.md .. Meetings/2023/2023-01-11.md
meetings/2023/2023-01-18.md .. Meetings/2023/2023-01-18.md
meetings/2023/2023-01-25.md .. Meetings/2023/2023-01-25.md
meetings/2023/2023-02-01.md .. Meetings/2023/2023-02-01.md
meetings/2023/2023-02-08.md .. Meetings/2023/2023-02-08.md
meetings/2023/2023-02-15.md .. Meetings/2023/2023-02-15.md
meetings/2023/2023-02-22.md .. Meetings/2023/2023-02-22.md
meetings/2023/2023-03-01.md .. Meetings/2023/2023-03-01.md
meetings/2023/2023-03-08.md .. Meetings/2023/2023-03-08.md
meetings/2023/2023-03-15.md .. Meetings/2023/2023-03-15.md
meetings/2023/2023-03-22.md .. Meetings/2023/2023-03-22.md
meetings/2023/2023-03-29.md .. Meetings/2023/2023-03-29.md
meetings/2023/2023-04-12.md .. Meetings/2023/2023-04-12.md
meetings/2023/2023-04-19.md .. Meetings/2023/2023-04-19.md
meetings/2023/2023-04-26.md .. Meetings/2023/2023-04-26.md
meetings/2023/2023-05-03.md .. Meetings/2023/2023-05-03.md
meetings/2023/2023-05-10.md .. Meetings/2023/2023-05-10.md
meetings/2023/2023-05-17.md .. Meetings/2023/2023-05-17.md
meetings/2023/2023-05-24.md .. Meetings/2023/2023-05-24.md
meetings/2023/2023-05-31.md .. Meetings/2023/2023-05-31.md
meetings/2023/2023-06-07.md .. Meetings/2023/2023-06-07.md
meetings/2023/2023-06-14.md .. Meetings/2023/2023-06-14.md
meetings/2023/2023-06-21.md .. Meetings/2023/2023-06-21.md
meetings/2023/2023-06-28.md .. Meetings/2023/2023-06-28.md
meetings/2023/2023-07-05.md .. Meetings/2023/2023-07-05.md
meetings/2023/2023-07-12.md .. Meetings/2023/2023-07-12.md
meetings/2023/2023-07-19.md .. Meetings/2023/2023-07-19.md
meetings/2023/2023-07-26.md .. Meetings/2023/2023-07-26.md
meetings/2023/2023-08-02.md .. Meetings/2023/2023-08-02.md
meetings/2023/2023-08-09.md .. Meetings/2023/2023-08-09.md
meetings/2023/2023-08-16.md .. Meetings/2023/2023-08-16.md
meetings/2023/2023-08-23.md .. Meetings/2023/2023-08-23.md
meetings/2023/2023-08-30.md .. Meetings/2023/2023-08-30.md
meetings/2023/2023-09-06.md .. Meetings/2023/2023-09-06.md
meetings/2023/2023-09-13.md .. Meetings/2023/2023-09-13.md
meetings/2023/2023-09-20.md .. Meetings/2023/2023-09-20.md
meetings/2023/2023-09-27.md .. Meetings/2023/2023-09-27.md
meetings/2023/2023-10-11.md .. Meetings/2023/2023-10-11.md
meetings/2023/2023-10-18.md .. Meetings/2023/2023-10-18.md
meetings/2023/2023-10-25.md .. Meetings/2023/2023-10-25.md
meetings/2023/2023-11-01.md .. Meetings/2023/2023-11-01.md
meetings/2023/2023-11-08.md .. Meetings/2023/2023-11-08.md
meetings/2023/2023-11-15.md .. Meetings/2023/2023-11-15.md
meetings/2023/2023-11-22.md .. Meetings/2023/2023-11-22.md
meetings/2023/2023-11-29.md .. Meetings/2023/2023-11-29.md
meetings/2023/2023-12-06.md .. Meetings/2023/2023-12-06.md
meetings/2023/2023-12-13.md .. Meetings/2023/2023-12-13.md
meetings/2023/2023-12-20.md .. Meetings/2023/2023-12-20.md
meetings/2024/2024-01-10.md .. Meetings/2024/2024-01-10.md
meetings/2024/2024-01-17.md .. Meetings/2024/2024-01-17.md
meetings/2024/2024-01-24.md .. Meetings/2024/2024-01-24.md
meetings/2024/2024-01-31.md .. Meetings/2024/2024-01-31.md
meetings/2024/2024-02-07.md .. Meetings/2024/2024-02-07.md
meetings/2024/2024-02-14.md .. Meetings/2024/2024-02-14.md
meetings/2024/2024-02-21.md .. Meetings/2024/2024-02-21.md
meetings/2024/2024-02-28.md .. Meetings/2024/2024-02-28.md
meetings/2024/2024-03-06.md .. Meetings/2024/2024-03-06.md
meetings/2024/2024-03-13.md .. Meetings/2024/2024-03-13.md
meetings/2024/2024-03-20.md .. Meetings/2024/2024-03-20.md
meetings/2024/2024-03-27.md .. Meetings/2024/2024-03-27.md
meetings/2024/2024-04-03.md .. Meetings/2024/2024-04-03.md
meetings/2024/2024-04-10.md .. Meetings/2024/2024-04-10.md
meetings/2024/2024-04-17.md .. Meetings/2024/2024-04-17.md
meetings/2024/2024-04-24.md .. Meetings/2024/2024-04-24.md
meetings/2024/2024-05-01.md .. Meetings/2024/2024-05-01.md
meetings/2024/2024-05-08.md .. Meetings/2024/2024-05-08.md
meetings/2024/2024-05-15.md .. Meetings/2024/2024-05-15.md
meetings/2024/2024-05-22.md .. Meetings/2024/2024-05-22.md
meetings/2024/2024-05-29.md .. Meetings/2024/2024-05-29.md
meetings/2024/2024-06-05.md .. Meetings/2024/2024-06-05.md
meetings/2024/2024-06-19.md .. Meetings/2024/2024-06-19.md
meetings/2024/2024-06-26.md .. Meetings/2024/2024-06-26.md
meetings/2024/2024-07-03.md .. Meetings/2024/2024-07-03.md
meetings/2024/2024-07-10.md .. Meetings/2024/2024-07-10.md
meetings/2024/2024-07-17.md .. Meetings/2024/2024-07-17.md
meetings/2024/2024-07-24.md .. Meetings/2024/2024-07-24.md
meetings/2024/2024-07-31.md .. Meetings/2024/2024-07-31.md
meetings/2024/2024-08-07.md .. Meetings/2024/2024-08-07.md
meetings/2024/2024-08-14.md .. Meetings/2024/2024-08-14.md
meetings/2024/2024-08-21.md .. Meetings/2024/2024-08-21.md
meetings/2024/2024-08-28.md .. Meetings/2024/2024-08-28.md
meetings/2024/2024-09-04.md .. Meetings/2024/2024-09-04.md
meetings/2024/2024-09-11.md .. Meetings/2024/2024-09-11.md
meetings/2024/2024-09-18.md .. Meetings/2024/2024-09-18.md
meetings/2024/2024-09-25.md .. Meetings/2024/2024-09-25.md
meetings/2024/2024-10-02.md .. Meetings/2024/2024-10-02.md
meetings/2024/2024-10-09.md .. Meetings/2024/2024-10-09.md
meetings/2024/2024-10-16.md .. Meetings/2024/2024-10-16.md
meetings/2024/2024-10-23.md .. Meetings/2024/2024-10-23.md
meetings/2024/2024-10-30.md .. Meetings/2024/2024-10-30.md
meetings/2024/2024-11-06.md .. Meetings/2024/2024-11-06.md
meetings/2024/2024-11-13.md .. Meetings/2024/2024-11-13.md
meetings/2024/2024-11-20.md .. Meetings/2024/2024-11-20.md
meetings/2024/2024-11-27.md .. Meetings/2024/2024-11-27.md
meetings/2024/2024-12-04.md .. Meetings/2024/2024-12-04.md
meetings/2024/2024-12-11.md .. Meetings/2024/2024-12-11.md
meetings/2025/2025-01-08.md .. Meetings/2025/2025-01-08.md
meetings/2025/2025-01-15.md .. Meetings/2025/2025-01-15.md
meetings/2025/2025-01-22.md .. Meetings/2025/2025-01-22.md
meetups/2013-munich.md .. Meetups/2013-Munich.md
meetups/2014-munich.md .. Meetups/2014-Munich.md
meetups/2015-delft.md .. Meetups/2015-Delft.md
meetups/2016-helsinki.md .. Meetups/2016-Helsinki.md
meetups/2017-karlsruhe.md .. Meetups/2017-Karlsruhe.md
meetups/2018-lviv.md .. Meetups/2018-Lviv.md
meetups/2019-trento.md .. Meetups/2019-Trento.md
meetups/2021-munich.md .. Meetups/2021-Munich.md
meetups/2022-delft.md .. Meetups/2022-Delft.md
meetups/2023-orihuela.md .. Meetups/2023-Orihuela.md
meetups/2024-karlsruhe.md .. Meetups/2024-Karlsruhe.md
meetups/2025-naples.md .. Meetups/2025-Naples.md
/dev/null .. Security Announcements/CCSInjection.md
@@ 0,0 1,18 @@
+	# OpenSSL CCS Injection Vulnerability (CVE-2014-0224)
+	On June 5th, 2014, a number of vulnerabilities in OpenSSL were disclosed (see [OpenSSL Security Advisory](https://www.openssl.org/news/secadv_20140605.txt)). One of those, the CCS Injection Vulnerability, affects OpenVPN. This page discusses the consequences for OpenVPN users.
+
+	## What does the CCS Injection Vulnerability mean?
+	In short: if both the client and the server are running a vulnerable version of OpenSSL, an active attacker with a man-in-the-middle position can trick OpenSSL to use keys known to the attacker. This means the attacker can read and even manipulate everything on the TLS connection. In the OpenVPN case, that includes the traffic protection keys for your VPN data, and thus your VPN data. For more information, visit the CCS Injection Vulnerability page at [Lepidum](http://ccsinjection.lepidum.co.jp/) or check the CVE at [CVE-2014-0224](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0224).
+
+	Use of [TLS auth](Hardening#Useof--tls-auth) prevents this vulnerability from being exploited.
+
+	## What should I do?
+	- Update your OpenSSL and restart OpenVPN (and any other daemons using it).
+	- If you're using the OpenVPN Windows installer upgrade to the [latest OpenVPN release](http://openvpn.net/index.php/download/community-downloads.html).
+	- Use TLS-auth as an extra layer of protection (see [Hardening](wiki:Hardening#Useof--tls-auth)).
+
+	## Do I need to create new private keys and certificates?
+	No, those are not leaked by this vulnerability. The keys an attacker could intercept are the temporary TLS and VPN data channel keys, which are freshly generated for each new connection.
+
+	## Do the six other OpenSSL vulnerabilities affect OpenVPN?
+	No. Current OpenVPN releases (that is, up to 2.3.4) do not use DTLS, SSL_MODE_RELEASE_BUFFERS or ECDH, and are thus not affected by bugs in those components.
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2016-10229.md
@@ 0,0 1,15 @@
+	# CVE-2016-10229: Linux kernel, UDP and use of MSG_PEEK
+
+	OpenVPN does not make use of the MSG_PEEK feature when processing packets from a remote system, and therefore OpenVPN is not impacted by this bug.
+
+	## References
+	- [Security Focus BID 97397](http://www.securityfocus.com/bid/97397)
+	- [Linux Kernel Commit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=197c949e7798fbf28cfadc69d9ca0c2abbf93191)
+
+	### Distribution notes
+	- **Red Hat Enterprise Linux**: [Solution 3001781](https://access.redhat.com/solutions/3001781), [Bugzilla CVE-2016-10229](https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-10229)
+	- **SUSE Enterprise Linux**: [SUSE Security CVE-2016-10229](https://www.suse.com/security/cve/CVE-2016-10229/)
+	- **Debian**: [Debian Security Tracker CVE-2016-10229](https://security-tracker.debian.org/tracker/CVE-2016-10229)
+	- **Ubuntu**: [Ubuntu CVE Tracker](https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-10229.html)
+	- **Arch**: [Arch Security CVE-2016-10229](https://security.archlinux.org/CVE-2016-10229)
+	- **Android**: [Android Security Bulletin April 2017](https://source.android.com/security/bulletin/2017-04-01)
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2017-12166.md
@@ 0,0 1,51 @@
+	# CVE-2017-12166: Out of Bounds Write in Key-Method 1
+
+	OpenVPN versions 2.4.4 and 2.3.18 resolve an out-of-bounds write vulnerability discovered by Guido Vranken.
+
+	This vulnerability is only exposed when `key-method 1` is explicitly selected in the config or on the command line. This option is available solely for backward compatibility with OpenVPN 1.x and has not been the default since the release of OpenVPN 2.0 in 2005. It will be completely removed in OpenVPN 2.5.
+
+	## Commit Message
+
+	```
+	Fix bounds check in read_key()
+
+	The bounds check in read_key() was performed after using the value,
+	instead of before. If 'key-method 1' is used, this allowed an attacker to send a
+	malformed packet to trigger a stack buffer overflow.
+
+	Fix this by moving the input validation to before the writes.
+
+	Note that 'key-method 1' has been replaced by 'key method 2' as the default
+	in OpenVPN 2.0 (released on 2005-04-17), and explicitly deprecated in 2.4
+	and marked for removal in 2.5. This should limit the amount of users
+	impacted by this issue.
+
+	CVE: 2017-12166
+	Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
+	Acked-by: Gert Doering <gert@greenie.muc.de>
+	Acked-by: David Sommerseth <davids@openvpn.net>
+	Message-Id: <80690690-67ac-3320-1891-9fecedc6a1fa@fox-it.com>
+	URL: https://www.mail-archive.com/search?l=mid&q=80690690-67ac-3320-1891-9fecedc6a1fa@fox-it.com
+	Signed-off-by: David Sommerseth <davids@openvpn.net>
+	```
+
+	## Mail Thread Reporting the Vulnerability
+
+	[OpenVPN-devel mailing list thread](https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15492.html)
+
+	## Fixes in Tree
+
+	- **Master Branch**
+	- commit 3b1a61e9fb27213c46f76312f4065816bee8ed01
+
+	- **Release/2.4 Branch**
+	- commit c7e259160b28e94e4ea7f0ef767f8134283af255
+
+	- **Release/2.3 Branch**
+	- commit fce34375295151f548a26c2d0eb30141e427c81a
+
+	- **Release/2.2 Branch**
+	- commit a9f5c744d6b09f2495ca48d2c926efd3a4b981e6
+
+	- **Release/2.1 Branch**
+	- commit c560f95e7038daa3a1b5a08b69b85fb68d4eeef3
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2018-7544.md
@@ 0,0 1,129 @@
+	# [DRAFT] CVE-2018-7544: **DISPUTED** Remote Information Disclosure and Denial Of Service
+
+	Jose Antonio Pérez Piedra discovered a method to interfere with an active OpenVPN instance through the management interface and reported this as a security issue to the OpenVPN developers. They disagreed with the assessment and classified it as a configuration problem (non-default). Jose disagreed and proceeded to secure a CVE ID ([CVE-2018-7544](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7544)).
+
+	As the existence of a CVE may create insecurity and confusion for OpenVPN users, this page aims to clarify the situation, explain why it is not deemed a security issue, and why no code changes will be made to disallow the configuration variant in question.
+
+	## Why do we dispute this CVE?
+
+	### 1. Management interface is disabled by default
+
+	OpenVPN does not enable the management interface by default; it must be explicitly enabled. The documentation has long recommended:
+
+	```
+	It is strongly recommended that IP be set to 127.0.0.1 (localhost) to
+	restrict accessibility of the management server to local clients.
+	```
+
+	Since OpenVPN 2.1, it has also been possible to use a Unix socket instead of a TCP socket for the management interface on platforms where this is available. Only the Windows platform cannot use a Unix socket out-of-the-box.
+
+	### 2. Management interface access is exclusive
+
+	The management interface is designed to be exclusive to a single connection only. A configuration setup that uses the management interface is expected to connect to it as soon as possible. Any other clients trying to connect will not be able to connect.
+
+	### 3. Management interface is forgiving by design
+
+	It is claimed to be an issue that the management interface accepts bogus/invalid input before and/or after valid management commands. This is by design. This allows users of the management to check for availability of features regardless of the OpenVPN version running without risking disruptions of the currently running process.
+
+	### 4. The management interface supports password authentication
+
+	Since early OpenVPN 2.0, the management interface has supported the use of simple password authentication to gain access. This adds another layer of protection, especially when the management interface is used over TCP. However, because TCP communication is not encrypted, it should be clear this is not intended to be used over an insecure network, more commonly via localhost (127.0.0.1) - or even better, a Unix socket.
+
+	### 5. The management interface's availability
+
+	The Windows GUI is the most commonly used OpenVPN interface on Windows, which facilitates the use of the management and has done so since OpenVPN 2.3_alpha1. OpenVPN on Windows prior to this release did not use the management interface. As of v2.3_alpha1 and since then, the management interface is configured with a randomly generated password for each tunnel instance. This password is unique per running instance and never re-used.
+
+	Another widely used management interface user on the client side is the NetworkManager's OpenVPN plug-in. This has for a long time not used TCP connections, but uses Unix sockets.
+
+	On the server side, the OpenVPN Access Server is using the management interface as well. For VPN clients to be able to establish a VPN connection, the management process must be connected to the management interface at all times. If it is not connected, clients will not be able to authenticate. Access Server is designed to ensure the management process is always connected to the OpenVPN server processes it is expected to manage.
+
+	Further, there exists no standard or recommended port number to use for the management interface. Thus an attacker is forced to do a local port scan and check if it is an OpenVPN management interface responding. In addition to this, the timing is also crucial. For an attacker to successfully gain control, it must do so before the legitimate management process gets a chance to connect. If there are implementers concerned about this race condition, they need to consider using the `--management-client` option. This makes OpenVPN become a connecting client instead of a server accepting connections. The service process making use of the management interface with this option will then need to listen for the OpenVPN process to connect to itself.
+
+	Thus, this is a configuration and implementation issue of the service making use of the management interface.
+
+	### 6. OpenVPN cannot protect users against improper configuration or usage by itself
+
+	OpenVPN is often considered to be the Swiss Knife of VPNs, due to its flexibility and features. That means: There are some blades which will hurt you if not used properly, and some blades are worse than others.
+
+	OpenVPN (or any other network-enabled service) cannot protect itself or its users against incorrect configurations. If OpenVPN is configured to open a management interface, OpenVPN expects the management interface to be used according to its design. The core OpenVPN process (`/usr/sbin/openvpn`, `openvpn.exe`) itself is not aimed to be used by non-technical users directly, it is supposed to be used via a more user-friendly interface. For graphical desktops, this is fairly obvious; there are plenty of end-user front-ends (OpenVPN GUI, Tunnelblick, Viscosity, NetworkManager, etc.). For servers and headless computers, this most commonly happens via various service management tools (like init.d/upstart/systemd or Windows-based service management tools). This is needed because the OpenVPN process needs elevated privileges to be able to configure the VPN tunnel and the network routing; these end-user front-ends take care of handling this privilege escalation properly for the core OpenVPN process.
+
+	This essentially means:
+
+	* Any configuration using the management interface needs to have a management service connecting to the interface as soon as possible and keep the connection during the lifetime of the VPN tunnel; alternatively, the management service is listening for the OpenVPN process to connect to by using the `--management-client` option.
+	* Wherever applicable, use a Unix socket in favor of TCP sockets.
+	* Enable password authentication, at least when using TCP sockets.
+
+	Not complying with these three simple points is considered a "you know what you are doing at your own risk" configuration.
+
+	It could also be argued that the management interface is enabled in configuration files provided by a VPN service provider or similar. Again, this is improper usage of OpenVPN if there are no management service processes activating the core OpenVPN process. OpenVPN end-users should get the configuration file from a well-known and trusted source, if it has not already been installed by a system or network admin. OpenVPN itself cannot account for or try to protect users against using a configuration file from a non-trusted source. Users who use OpenVPN configuration files downloaded from untrusted sources are taking much bigger risks than the possibility that their management interface gets abused.
+
+	### Conclusion
+
+	OpenVPN does not enable management interface by default. Also, if the management interface is properly configured and used, there are no known security issues with it. Any configuration that enables the management interface over TCP without setting a password is considered improperly configured. Further, any configuration that enables the management interface without actually connecting to it is considered improper.
+
+	## What has been done
+
+	The OpenVPN core developers acknowledge that the documentation has not been too explicit on the risks of using the TCP interface. But the core developers are at the same time surprised some might not find this obvious and clear for anyone making use of a TCP enabled service without a password.
+
+	Regardless, to make this explicit two patches have been added to better highlight such potential improper usage:
+
+	```
+	commit e5ee5121cbbeca6dcbee38dea5b40779e3f6da83
+	Author: David Sommerseth
+	Date: Wed Feb 28 14:19:17 2018 +0100
+
+	man: Reword --management to prefer unix sockets over TCP
+
+	It is more secure to use unix sockets instead of TCP ports for the
+	management interface, so reword it and provide some details why TCP is
+	not recommended.
+
+	Also re-arranged this section to be somewhat easier to read and clearer
+	on a few related details.
+
+	Signed-off-by: David Sommerseth
+	Acked-by: Gert Doering
+	URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg16573.html
+	Signed-off-by: Gert Doering
+	(cherry picked from commit ec100d7e4ce7aaeb731c22b0d86826bf295df6cd)
+	```
+
+	This was added to the OpenVPN 2.4.5 release and updates the man page to explicitly state:
+
+	```
+	BEWARE of enabling the management interface over TCP. In these
+	cases you should ALWAYS make use of pw-file to password protect
+	the management interface. Any user who can connect to this TCP
+	IP:port will be able to manage and control (and interfere with)
+	the OpenVPN process. It is also strongly recommended to set IP
+	to 127.0.0.1 (localhost) to restrict accessibility of the man-
+	agement server to local clients.
+	```
+
+	Further, the following patch is in the queue for the OpenVPN 2.4.6 release:
+
+	```
+	commit ab218befec67dc0f5bb08973d2ec3476350f9ab3
+	Author: David Sommerseth
+	Date: Wed Feb 28 14:19:18 2018 +0100
+
+	management: Warn if TCP port is used without password
+
+	It is not recommended to use --management on a TCP port without also
+	adding a password authentication, as this can easily be abused by other
+	users or processes being able to connect to the management interface.
+
+	Thus issue a warning that this configuration is strongly discouraged.
+
+	Signed-off-by: David Sommerseth
+	Acked-by: Gert Doering
+	URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg16574.html
+	Signed-off-by: Gert Doering
+	(cherry picked from commit 4db7715a3aa62f2e8d8234c1852fb141f62318e2)
+	```
+
+	This results in the following line to be seen in the logs whenever the management interface is enabled on a TCP port without a password enabled:
+
+	```
+	WARNING: Using --management on a TCP port WITHOUT passwords is STRONGLY discouraged and considered insecure
+	```
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2020-15078.md
@@ 0,0 1,31 @@
+	# CVE-2020-15078
+
+	## Overview
+
+	OpenVPN 2.5.1 and earlier versions allow remote attackers to bypass authentication and access control channel data on servers configured with deferred authentication, which can be used to potentially trigger further information leaks.
+
+	## Detailed Description
+
+	This bug permits - under very specific circumstances - tricking a server using delayed authentication (either via a plugin or management) into returning a PUSH_REPLY before the AUTH_FAILED message, which can possibly be used to gather information about a VPN setup.
+
+	In conjunction with "--auth-gen-token" or a user-specific token auth solution, it may be possible to access a VPN with an otherwise-invalid account.
+
+	## Fixed OpenVPN Versions
+
+	This vulnerability has been addressed in the following releases:
+
+	- **release/2.5**
+	- Commit f7b3bf067ffce72e7de49a4174fd17a3a83f0573
+	- Commit 3d18e308c4e7e6f7ab7c2826c70d2d07b031c18a
+	- Commit 3aca477a1b58714754fea3a26d0892fffc51db6b
+	- **release/2.4**
+	- Commit 0e5516a9d656ce86f7fb370c824344ea1760c255
+
+	The following releases include the fix:
+
+	- OpenVPN 2.5.2
+	- OpenVPN 2.4.11
+
+	## Recommendations
+
+	If you are not using `auth-gen-token`, a plugin, or management in your configuration, your setup should be safe. However, if in doubt, consider upgrading. If you know you're using deferred-auth, it is recommended to upgrade.
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2021-3547.md
@@ 0,0 1,5 @@
+	# CVE-2021-3547: OpenVPN 3 Core library 3.6 and 3.6.1 possible certificate authentication bypass with `--verify-x509-name`
+
+	OpenVPN 3 Core Library version 3.6 and 3.6.1 allows a man-in-the-middle attacker to bypass the certificate authentication by issuing an unrelated server certificate using the same hostname found in the `verify-x509-name` option in a client configuration.
+
+	This issue is resolved in OpenVPN 3 Core library 3.6.2, by [commit febf01ef68](https://github.com/OpenVPN/openvpn3/commit/febf01ef68b84f1579684224c80149138b6d2dcc) and [commit 11f964076d](https://github.com/OpenVPN/openvpn3/commit/11f964076d1c8c394f679b00a0242424a98b88d8).
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2021-3606.md
@@ 0,0 1,7 @@
+	## CVE-2021-3606: OpenVPN 2.5.2 and earlier versions (Windows only) may load an external OpenSSL configuration file
+
+	OpenVPN before version 2.5.3 on Windows allows local users to load arbitrary dynamic loadable libraries via an OpenSSL configuration file if present, which allows the user to run arbitrary code with the same privilege level as the main OpenVPN process (openvpn.exe).
+
+	This issue affects only OpenVPN 2.5.2 and prior releases only on Windows, as this related to how the OpenSSL library is built. This is not an issue in the OpenVPN code itself, but due to a feature available by default in the OpenSSL library. From OpenVPN 2.5.3, this feature is being disabled at compile-time of the OpenSSL library which results in no external OpenSSL configuration files being loaded from specific folders on the local system.
+
+	This issue was reported by Xavier Danest.
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2022-0547.md
@@ 0,0 1,11 @@
+	# CVE-2022-0547: Potential Authentication By-pass with Multiple Deferred Authentication Plug-ins
+
+	OpenVPN versions 2.1 up to 2.4.11 and 2.5.5 may allow for an authentication bypass in scenarios where more than one external authentication plug-in utilizes deferred authentication replies. This vulnerability could permit an external user to gain access using only partially correct credentials.
+
+	This issue has been addressed in OpenVPN versions 2.4.12 and 2.5.6. In these versions, the OpenVPN server process will terminate and log the following error message:
+
+	```
+	Exiting due to multiple authentication plug-ins performing deferred authentication. Only one authentication plug-in doing deferred auth is allowed. Ignoring the result and stopping now, the current authentication result is not to be trusted.
+	```
+
+	MITRE entry for more details: [CVE-2022-0547](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0547)
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2023-46849.md
@@ 0,0 1,7 @@
+	# CVE-2023-46849: Use of --fragment option can lead to a division by zero error which can be fatal
+
+	OpenVPN 2.6 from version 2.6.0 up to and including version 2.6.6 incorrectly restores the "--fragment" configuration under certain conditions. This can result in a division by zero error. On platforms where a division by zero is fatal, this will cause OpenVPN to crash.
+
+	This issue has been resolved in OpenVPN 2.6.7.
+
+	MITRE entry: [CVE-2023-46849](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-46849)
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2023-46850.md
@@ 0,0 1,7 @@
+	# CVE-2023-46850: Incorrect use of send buffer can cause memory to be sent to peer
+
+	OpenVPN 2.6 from version 2.6.0 up to and including 2.6.6 incorrectly uses a send buffer after it has been freed in some circumstances. This error causes some freed memory to be sent to the peer. All configurations using TLS (i.e., not using `--secret`) are affected by this issue.
+
+	This issue is resolved in OpenVPN 2.6.7.
+
+	**MITRE entry**: [CVE-2023-46850](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-46850)
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2023-6247.md
@@ 0,0 1,15 @@
+	# CVE-2023-6247: PKCS!#7 Parser in OpenVPN 3 Core Library Can Result in NULL-Dereference
+
+	The PKCS!#7 parser in OpenVPN 3 Core Library versions through 3.8.3 did not properly validate the parsed data, which would result in the application crashing.
+
+	This issue has been resolved in OpenVPN 3 Core Library version 3.8.4.
+
+	## Note
+
+	The code paths related to this issue are never used for OpenVPN connections. The affected code is only used in some of the AWS API support functionality present in the library.
+
+	## References
+
+	- MITRE CVE Record: [https://www.cve.org/CVERecord?id=CVE-2023-6247](https://www.cve.org/CVERecord?id=CVE-2023-6247)
+	- OpenVPN 3 Core commit: [https://github.com/OpenVPN/openvpn3/commit/afdfe1bb3f4c54e8794](https://github.com/OpenVPN/openvpn3/commit/afdfe1bb3f4c54e8794)
+	- Reported by: Bahaa Naamneh
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2023-7235.md
@@ 0,0 1,8 @@
+	# CVE-2023-7235: OpenVPN 2.x GUI Privilege Escalation Possible if Installed Outside Default Installation Path on Windows
+
+	When OpenVPN 2 GUI is installed on Windows in a non-standard installation directory, the installation directory's access control is not properly restricted. Windows, by default, assigns very open permissions, making any directory outside of standard system paths writable to anyone. This vulnerability allows an attacker to replace the OpenVPN service component with malicious code, gaining increased control over the host when the OpenVPN service process is restarted.
+
+	## References
+	- Release notes: [https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg07456.html](https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg07456.html)
+	- CVE record: [https://www.cve.org/CVERecord?id=CVE-2023-7235](https://www.cve.org/CVERecord?id=CVE-2023-7235)
+	- Reported by: Will Dormann (Analygence, Inc)
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2024-1305.md
@@ 0,0 1,10 @@
+	# CVE-2024-1305: Windows TAP driver: Fix potential integer overflow in TapSharedSendPacket
+
+	This could lead to an integer overflow, resulting in the allocation of a smaller memory size, which may then cause a buffer overflow and a bug check.
+
+	The fix involves checking for overflow conditions and failing the IRP if an overflow occurs.
+
+	## References
+	- Release notes: [https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg07534.html](https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg07534.html)
+	- CVE record: [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-1305](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-1305)
+	- Reported by: Vladimir Tokarev <vtokarev@microsoft.com>
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2024-13454.md
@@ 0,0 1,38 @@
+	## CVE-2024-13454 - Easy-RSA with OpenSSL 3 may create a CA private key using 3DES
+
+	Easy-RSA versions after 3.0.5 and before 3.2.0, when used with OpenSSL 3, incorrectly encrypt password-protected CA private keys using the `des-ede3-cbc` cipher through the `easyrsa build-ca` command. The expected cipher is `aes-256-cbc`.
+
+	### How to Fix the Private CA Key:
+	- Use the `easyrsa set-pass ca` command to re-encrypt the private CA key using the correct cipher algorithm. This is compatible across all Easy-RSA versions.
+
+	### Additional Recommendation:
+	- Upgrade to Easy-RSA version 3.2.0 or newer.
+
+	The `set-pass` command was introduced in Easy-RSA v3.1.2 ([GitHub PR #756](https://github.com/OpenVPN/easy-rsa/pull/756)).
+
+	### Workflow Using OpenSSL v3 with Easy-RSA:
+	For each version of Easy-RSA from v3.0.5 through v3.2.1, using `build-ca` and then `set-pass ca` to re-encrypt the CA key with a new password:
+
+	- **Note**: Support for OpenSSL v3 was first introduced in Easy-RSA v3.1.0 ([GitHub PR #492](https://github.com/OpenVPN/easy-rsa/pull/492)).
+
+	| Version | build-ca | set-pass |
+	|---------------|------------------|-----------------|
+	| EasyRSA-3.0.5 | des-ede3-cbc | aes-256-cbc |
+	| EasyRSA-3.0.6 | des-ede3-cbc | aes-256-cbc |
+	| EasyRSA-3.0.7 | des-ede3-cbc | aes-256-cbc |
+	| EasyRSA-3.0.8 | des-ede3-cbc | aes-256-cbc |
+	| EasyRSA-3.0.9 | des-ede3-cbc | aes-256-cbc |
+	| EasyRSA-3.1.0 | des-ede3-cbc | aes-256-cbc |
+	| EasyRSA-3.1.1 | des-ede3-cbc | aes-256-cbc |
+	| EasyRSA-3.1.2 | des-ede3-cbc | aes-256-cbc |
+	| EasyRSA-3.1.3 | des-ede3-cbc | aes-256-cbc |
+	| EasyRSA-3.1.4 | des-ede3-cbc | aes-256-cbc |
+	| EasyRSA-3.1.5 | des-ede3-cbc | aes-256-cbc |
+	| EasyRSA-3.1.6 | des-ede3-cbc | aes-256-cbc |
+	| EasyRSA-3.1.7 | des-ede3-cbc | aes-256-cbc |
+	| EasyRSA-3.2.0 | aes-256-cbc | aes-256-cbc |
+	| EasyRSA-3.2.1 | aes-256-cbc | aes-256-cbc |
+
+	OpenSSL versions `1.1.0l` and `1.1.1w` have been tested without issues. OpenSSL 1.x does not exhibit this issue.
+
+	However, the `set-rsa-pass` and `set-ec-pass` commands have been noted to change the CA key format from PKCS12 to PKC8 for Easy-RSA versions 3.0.9 through 3.1.7, with the cipher consistently being `aes-256-cbc`.
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2024-24974.md
@@ 0,0 1,12 @@
+	# CVE-2024-24974: Windows: Disallow Access to the Interactive Service Pipe from Remote Computers
+
+	`interactive.c`: Disable remote access to the service pipe.
+
+	Remote access to the service pipe is not necessary and could potentially serve as an attack vector.
+
+	For instance, if an attacker obtains credentials for a user who is a member of the "OpenVPN Administrators" group on a target machine, they might be able to communicate with the privileged interactive service on that machine and initiate OpenVPN processes remotely.
+
+	## References
+	- Release notes: [https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg07534.html](https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg07534.html)
+	- CVE record: [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-24974](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-24974)
+	- Reported by: Vladimir Tokarev <vtokarev@microsoft.com>
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2024-27459.md
@@ 0,0 1,14 @@
+	# CVE-2024-27459: Windows: fix a possible stack overflow in the interactive service component which might lead to a local privilege escalation
+
+	**File:** `interactive.c`
+
+	**Issue:** Fix potential stack overflow issue
+
+	When reading a message from the pipe, we first peek at the pipe to get the size of the message waiting to be read and then read the message. A compromised OpenVPN process could send an excessively large message, which would result in a stack-allocated message buffer overflow.
+
+	To address this, we terminate the misbehaving process if the peeked message size exceeds the maximum allowable size.
+
+	## References
+	- Release notes: [OpenVPN Users Mailing List](https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg07534.html)
+	- CVE record: [CVE-2024-27459](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-27459)
+	- Reported by: Vladimir Tokarev <vtokarev@microsoft.com>
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2024-27903.md
@@ 0,0 1,18 @@
+	# CVE-2024-27903: Windows: Disallow Loading of Plugins from Untrusted Installation Paths
+
+	**This security update prevents `openvpn.exe` from being attacked through malicious plugins by enforcing that plugins are only loaded from a trusted directory.**
+
+	## Updated Plugin Loading Behavior
+
+	Plugins for OpenVPN on Windows platforms will now only be allowed to load from the following trusted directories:
+
+	- Registry key `HKLM\SOFTWARE\OpenVPN\plugin_dir`. If this key is missing, then from `HKLM\SOFTWARE\OpenVPN`, which is the installation directory.
+	- The system directory.
+
+	**Note**: Loading from UNC paths is specifically disallowed to increase security.
+
+	## References
+
+	- [Release notes](https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg07534.html)
+	- [CVE record](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-27903)
+	- Reported by: Vladimir Tokarev <vtokarev@microsoft.com>
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2024-28882.md
@@ 0,0 1,12 @@
+	# CVE-2024-28882: OpenVPN in a server role accepts multiple exit notifications from authenticated clients which will extend the validity of a closing session
+
+	OpenVPN should only call `schedule_exit()` once for a given peer.
+
+	**Security scope:** An authenticated client can make the server "keep the session" even when the server has been told to disconnect this client.
+
+	**Affected versions:** 2.6.0 until 2.6.10 (inclusive)
+
+	## References
+	- Release notes: [OpenVPN Mailing List](https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg07634.html)
+	- CVE record: [CVE-2024-28882](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-28882)
+	- Reported by: Reynir Björnsson
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2024-4877.md
@@ 0,0 1,12 @@
+	# CVE-2024-4877: Windows: A malicious process may spoof the interactive service and potentially impersonate a local user
+
+	In `interactive.c` and OpenVPN-GUI for Windows:
+
+	A security vulnerability exists where an attacker without `SeImeprsonatePrivilege` could create a named pipe server with a name that matches the one used by the "Interactive Service". User interfaces such as OpenVPN-GUI, which connect to this named pipe, could be tricked into allowing the attacker to impersonate the user operating the interface.
+
+	To mitigate this issue, the security of the named pipe has been enhanced. Only processes running as SYSTEM (such as the interactive service) can now create a pipe with the same name. Additionally, to guard against any such pipes that were created before the service started, clients of the service are required to verify that the PID of the pipe server matches that of the service. These changes have been implemented in the OpenVPN-GUI for Windows.
+
+	## References
+	- Release notes: [https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg07634.html](https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg07634.html)
+	- CVE record: [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-4877](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-4877)
+	- Reported by: Zeze with TeamT5 <zeze7w@gmail.com>
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2024-5198.md
@@ 0,0 1,14 @@
+	# CVE-2024-5198: OpenVPN ovpn-dco for Windows Version 1.1.1 Vulnerability
+
+	OpenVPN ovpn-dco for Windows version 1.1.1 is vulnerable to a security issue where an unprivileged local attacker can send I/O control messages with invalid data to the driver. This results in a NULL pointer dereference, leading to a system halt.
+
+	**Affected versions:**
+	- ovpn-dco Windows driver 1.1.1
+	- OpenVPN 2.6.10-I002 Windows client
+
+	Note: Only the specified versions are affected. Older and newer versions of the driver and Windows client are not affected.
+
+	## References
+	- GitHub PR: [https://github.com/OpenVPN/ovpn-dco-win/pull/70](https://github.com/OpenVPN/ovpn-dco-win/pull/70)
+	- CVE record: [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-5198](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-5198)
+	- Reported-By: Lukas Jokubauskas <lukas.jokubauskas@nordsec.com>
\	No newline at end of file
/dev/null .. Security Announcements/CVE-2024-5594.md
@@ 0,0 1,8 @@
+	# CVE-2024-5594: Control Channel: Refuse Control Channel Messages with Nonprintable Characters in Them
+
+	**Security Scope:** A malicious OpenVPN peer can send garbage to OpenVPN log, or cause high CPU load.
+
+	## References
+	- Release notes: [https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg07634.html](https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg07634.html)
+	- CVE record: [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-5594](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-5594)
+	- Reported by: Reynir Björnsson
\	No newline at end of file
/dev/null .. Security Announcements/ExternalSecurityContacts.md
@@ 0,0 1,13 @@
+	## Introduction
+
+	This page lists security contacts for organizations that distribute software based on the OpenVPN project's code including OpenVPN, tap-windows6, and OpenVPN (Windows) GUI. All the organizations listed here have given their approval for being included here.
+
+	This list allows the OpenVPN project to send an advance notice to the organizations of any security fixes in OpenVPN and its subprojects. Details of the vulnerabilities will not be shared, but basic information such as "affected software", "is remotely exploitable", "severity rating", and "allows privilege escalation" is shared.
+
+	## Security Contacts List
+
+	The checkboxes show which subprojects the organization wants to get advance security notifications for.
+
+	| **Organization** | **Email** | **OpenVPN** | **Tap-windows6** | **OpenVPN-GUI** |
+	|------------------|-------------------|-------------|------------------|-----------------|
+	| Acme, Inc. | acme@example.org | X | X | X |
\	No newline at end of file
/dev/null .. Security Announcements/NSISBug1125.md
@@ 0,0 1,20 @@
+	OpenVPN Windows NSIS installers have three vulnerabilities described in [NSIS bug 1125](https://sourceforge.net/p/nsis/bugs/1125/). The most critical issue (!#1) enables running unsolicited code and an escalation of privilege attack through DLL Search Order Hijacking ([CAPEC-471](https://capec.mitre.org/data/definitions/471.html)) since OpenVPN installers are typically executed with Admin privileges. NSIS/Windows prefers loading DLLs from the current directory, which for the Downloads folder, is user-writable. This makes the exploit straightforward to execute, but only if a malicious DLL has already been placed in the user's Downloads folder.
+
+	The following installers have been built with an NSIS version that includes fixes for the three bugs:
+
+	- openvpn-install-2.4.4-I601
+	- openvpn-install-2.3.18-I601
+	- openvpn-install-2.3.18-I001
+
+	However, based on our testing, Windows 7 may still be vulnerable to at least issue !#1 as it lacks the API calls used by the fix. Newer versions of Windows, such as Windows 2012r2, are not vulnerable if the updated installers are used. Because these issues are complex to fully address in executable installers, we strongly recommend **not** running any installers, including those from OpenVPN, directly from the Downloads directory.
+
+	Our long-term plan is to start distributing OpenVPN as an MSI package.
+
+	This issue was brought to our attention by Stefan Kanthak.
+
+	Further details:
+
+	- [NSIS bug 1125](https://sourceforge.net/p/nsis/bugs/1125/)
+	- [CAPEC-471](https://capec.mitre.org/data/definitions/471.html)
+	- [Windows Desktop API reference](https://msdn.microsoft.com/en-us/library/windows/desktop/hh310515(v=vs.85).aspx)
+	- [Larry Osterman's blog on MSDN](http://blogs.msdn.com/b/larryosterman/archive/2004/07/19/187752.aspx)
\	No newline at end of file
/dev/null .. Security Announcements/QuarkslabAndCryptographyEngineerAudits.md
@@ 0,0 1,242 @@
+	# Introduction
+
+	OpenVPN 2.4.1 was simultaneously reviewed by Quarkslab (funded by OSTIF) and Cryptography Engineering LCC (funded by Private Internet Access). The reports have been published on OSTIF's and PIA's web pages:
+
+	- [OSTIF Report](https://ostif.org/?p=870&preview=true)
+	- [PIA Report](https://www.privateinternetaccess.com/blog/openvpn-2-4-2-fixes-critical-issues-discovered-openvpn-audit-reports/)
+
+	OpenVPN Technologies, Inc's official press release is here:
+
+	- [Press Release](http://www.prweb.com/releases/2017/05/prweb14326488.htm)
+
+	This page lists the findings in their respective reports and shows how the issues were resolved.
+
+	## Quarkslab findings
+
+	### Quarkslab 5.1: Pre-authentication Denial of Service
+
+	This issue has been assigned CVE-2017-7478.
+
+	An authenticated client can perform the 'three-way handshake' (P_HARD_RESET, P_HARD_RESET, P_CONTROL), where the P_CONTROL packet is the first that is allowed to carry payload. If that payload is too big, the OpenVPN server process will stop running due to an ASSERT() exception. Servers using tls-auth/tls-crypt are protected against this attack - the P_CONTROL packet is only accepted if it contains the session ID we specified, with a valid HMAC (challenge-response).
+
+	This affects OpenVPN 2.3.12 and newer. The problem has been fixed by commit "Don't assert out on receiving too-large control packets":
+
+	- release/2.3: feb35ee5ca
+	- release/2.4: 66b99a0753
+	- master: 5774cf4c25e
+
+	OpenVPN versions 2.3.15, 2.4.2, and later include these fixes.
+
+	### Quarkslab 5.2: Denial of Service due to Exhaustion of Packet-ID counter
+
+	This issue has been assigned CVE-2017-7479.
+
+	An authenticated client can cause the server's packet-id counter to roll over, which would lead the server process to hit an ASSERT() and stop running. To make the server hit the ASSERT(), the client must first cause the server to send it 2^32 packets (at least 196GB).
+
+	This problem is fixed by commit "Drop packets instead of asserting out if packet id rolls over":
+
+	- release/2.3: b727643cdf
+	- release/2.4: 591a4e574c
+	- master: e498cb0ea8
+
+	The fix requires commit "cleanup: merge packet_id_alloc_outgoing() into packet_id_write()" to apply cleanly (see commit 653d391922).
+
+	OpenVPN versions 2.4.2 and 2.3.15 (and later) include these fixes. The "release/2.2" branch in Git has also been patched, primarily for the benefit of external package maintainers. We do not, however, intend to make a 2.2-release, not even in source-only format.
+
+	### Quarkslab 5.3: Invalid Retrieval of X.509 Certificate Fields With mbed TLS
+
+	We agree with the report that the security impact of this finding is negligible. While no immediate action would have been necessary, this is fixed by commit "mbedtls: correctly check return value in pkcs11_certificate_dn()":
+
+	- release/2.4: 1ebd3ade
+	- master: 423bb16e
+
+	### Quarkslab 5.4: Usernames/Passwords not Erased from Memory
+
+	We agree with the analysis in the report. The likelihood of an occurrence of this issue in real life is exceptionally low since an attacker needs elevated privileges on the server to exploit this kind of information leak. The severity of this issue is therefore rated as very low.
+
+	This is fixed by commit "Always clear username/password from memory on error":
+
+	- release/2.4: 47d80b95
+	- master: 2b60198e
+
+	### Quarkslab 5.5: NULL Pointer Dereference in the Data Compression Stub
+
+	While this is a low-security issue, we will look into fixing this in a future release, as the fix is trivial.
+
+	### Quarkslab 5.6: Invalid Size Parameter Passed when Retrieving the Program Application Path
+
+	The report states that this is of "informational" severity as it can't be exploited. Regardless, we will fix this in a future release.
+
+	### Quarkslab 5.7: Leak of Service Manager Handles in OpenVPN GUI
+
+	This is an "informational" severity issue which we will fix in a future release of OpenVPN GUI.
+
+	## Cryptography Engineering findings
+
+	### OVPN-01: Sensitive authentication token not wiped on certain TLS authentication errors
+
+	This is fixed by commit "auth-token: Ensure tokens are always wiped on de-auth". Commit IDs per Git branch:
+
+	- release/2.4: a52fd9575e
+	- master: daab0a9fa8
+
+	### OVPN-02: Potentially flawed TLS control channel encryption
+
+	#### OVPN-02-1: Potentially flawed TLS control channel encryption: IV collision
+
+	This is a known issue and has been documented in the commit message of "Add control channel encryption (--tls-crypt)".
+
+	The wording "would result in a complete loss of privacy" in the report is cryptographic jargon that might mislead non-cryptographers reading the report to conclude that his/her traffic is no longer protected at all if such an IV collision occurs. That is of course not the case; tls-crypt is an additional layer of protection, and even if IVs collide, one of the packets is with high probability an (unpredictable) encrypted TLS record. Colliding IVs would of course result in ''some'' loss of privacy, but are unlikely to lead to a ''complete'' loss of privacy. As such, we believe "would result in a loss of privacy" is more appropriate.
+
+	We want to emphasize that `--tls-crypt` is protecting the OpenVPN control channel. The control channel is used to establish the TLS connection between server and client, where certificate information is used. The TLS protocol is designed so that the certificate information (which in essence is a public key, with some signed metadata such as Common Name, etc) is passed over connection in clear-text. This is not unique for OpenVPN, even HTTPS does it like this. So when enabling `--tls-crypt`, OpenVPN adds another layer of encryption only on this control channel. All the tunneled network traffic which is encrypted between the OpenVPN instances does not depend on --tls-crypt itself; thus the tunneled network traffic is not directly affected by this issue.
+
+	We have clarified the limitations of --tls-crypt in the man page, including recommendations for rekeying. We will also implement support for client-specific tls-auth/tls-crypt keys in a future OpenVPN release. This provides the option to trade some extra work during provisioning for mitigating this issue.
+
+	The relevant man page text:
+	```
+	All peers use the same --tls-crypt pre-shared group key to authenticate and encrypt control channel messages. To ensure that IV collisions remain unlikely, this key should not be used to encrypt more than 2^48 client-to-server or 2^48 server-to-client control channel messages. A typical initial negotiation is about 10 packets in each direction. Assuming both initial negotiation and renegotiations are at most 2^16 (65536) packets (to be conservative), and (re)negotiations happen each minute for each user (24/7), this limits the tls-crypt key lifetime to 8171 years divided by the number of users. So a setup with 1000 users should rotate the key at least once each eight years. (And a setup with 8000 users each year.)
+
+	If IV collisions were to occur, this could result in the security of --tls-crypt degrading to the same security as using --tls-auth. That is, the control channel still benefits from the extra protection against active man-in-the-middle-attacks and DoS attacks, but may no longer offer extra privacy and post-quantum security on top of what TLS itself offers.
+	```
+
+	The man-page fix is implemented by these commits:
+
+	- release/2.4: 9444506e
+	- master: 5806f66e
+
+	#### OVPN-02-2: Potentially flawed TLS control channel encryption: ciphertext is not MAC'ed
+
+	We believe that replacing authentication (`--tls-auth`) with authenticated encryption (`--tls-crypt`) does not introduce risks. At the exact place where `--tls-auth` authenticates the plaintext and checks for replays of control channel packets, `--tls-crypt` performs decryption, authenticates the plaintext, and checks for replays. Our analysis is that `--tls-crypt` provides the same DoS protection as `--tls-auth` does, with the sole exception that `--tls-crypt` requires slightly more work to authenticate a packet (specifically, one AES-CTR operation).
+
+	We do not see that encrypt-and-authenticate relates in any way to replay protection, which is always performed after authentication.
+
+	Finally, we are aware that MAC-then-encrypt is problematic for CBC cipher modes (or other modes that require padding), but this is not applicable to stream ciphers and in particular not to the SIV-construction[0] we use (with HMAC-SHA2 + AES-CTR).
+
+	[0] Rogaway & Shrimpton, A Provable-Security Treatment of the Key-Wrap Problem, 2006
+	(https://www.iacr.org/archive/eurocrypt2006/40040377/40040377.pdf)
+
+	### OVPN-03: Insecure configuration options
+
+	#### OVPN-03-1: Insecure configuration options: --prng
+
+	The current prng is non-standard, but seems to rely solely on the preimage-resistance of hash functions, which makes SHA1 (still) a sane default. This custom prng is mostly in place as a performant alternative for CBC IVs. ''It is not used to produce keys.''
+
+	Given the above, we see no need to change this right away. But we are considering two options for the internal prng:
+
+	1. Keep --prng but reject using MD4 or MD5
+	2. Rip out the OpenVPN prng implementation and rather use the crypto libraries' implementation directly. This has the side-effect of reduced performance in CBC-mode.
+
+	In regard to NIST compliance, OpenVPN users with such demands will need to configure and use OpenVPN in a compliant way (e.g. --prng SHA256).
+
+	#### OVPN-03-2: Insecure configuration options: --no-iv
+
+	The --no-iv option is an advanced feature that reduces security for a slight improvement in performance. This option has been deprecated in the release/2.4 branch (commit 4969f0d6bb) and removed in the master branch (commit ef910e3e3a). _It will not be present in OpenVPN 2.5._
+
+	#### OVPN-03-3: Insecure configuration options: --no-replay
+
+	The --no-replay is an advanced feature that allows disabling OpenVPN's replay attack protection. This option can only be used without reducing security if OpenVPN was already used in an insecure mode that disables authentication. We are considering deprecating this feature.
+
+	#### OVPN-03-4: Insecure configuration options: --reneg-bytes
+
+	The --reneg-bytes option can be used to disable SWEET32 mitigation in OpenVPN. The report suggests ignoring --reneg-bytes when 64-bit block ciphers such as Blowfish are used. In practice doing what the report suggests would break configurations that use OTP but cannot make use of --auth-gen-token. We believe that the current approach, where we use sane but overridable defaults and log warnings if small block ciphers are used, suffices.
+
+	We will review the warning messages and possibly make them more scary in v2.5. If people are still using weak ciphers in the 2.6 release cycle, we will consider doing what the report suggests.
+
+	#### OVPN-03-5: Defaulting to --cipher BF-CBC and --auth SHA1
+
+	We agree that it would be good to migrate to stronger algorithms such as SHA-2 and AES by default, but doing so would break lots of client setups.
+
+	Cipher negotiation (NCP) in OpenVPN 2.4 defaults to AES-256-GCM and allows negotiating stronger ciphers when clients support it. Using NCP is a more user-friendly way to migrating away from suboptimal defaults like BF-CBS and SHA-1.
+
+	We will continue looking into gradually upgrading the connection's crypto parameters without breaking existing configurations. Once that has been deployed and widely used for a longer time, we can truly consider changing the default values or deprecating the old way of setting ciphers.
+
+	#### OVPN-03-6: Insecure configuration options: encryption without authentication
+
+	This has been fixed in commit "Make --cipher/--auth none more explicit on the risks":
+
+	- release/2.4: 1935729fe6
+	- master: 7a1b6a0dd7
+
+	The commit modifies the warning messages to make it absolutely clear that using --auth none or --cipher none is a really bad idea.
+
+	### OVPN-04: Possible NULL pointer dereferences
+
+	#### OVPN-04-1: Possible NULL pointer derefence in contrib/keychain-mcd/cert_data.c
+
+	This code needs a considerable overhaul. It lacks a proper defensive coding style, where the crux of the issues is that there are basically no error checking on functions which may very well return NULL. This issue also goes deeper than what this report covers.
+
+	We have initiated a discussion in the community about getting this code fixed. In addition, we are discussing with the Tunnelblick maintainer if it would be more appropriate to transfer this code to the Tunnelblick project directly; the keychain-mcd contrib code is only targeting macOS.
+
+	#### OVPN-04-2: Possible NULL pointer dereference in sample-plugins/defer/simple.c
+
+	A complete rewrite of the sample-plugins/defer/simple.c example plug-in has been sent for review. This will replace simple.c completely and resolves both this issue and OVPN-07.
+
+	#### OVPN-04-3: Possible NULL pointer dereference in src/openvpn/proxy.c
+
+	Our analysis shows that the code path referred to in the report cannot fail. "la" is a zero-initialized struct buffer, that is only ever changed if "lookahead" is non-null:
+
+	```
+	struct buffer la;
+	int lastc = 0;
+
+	CLEAR(la);
+	if (lookahead)
+	{
+	la = *lookahead;
+	}
+	```
+	That means that `if (buf_defined(&la))` will always be false if `*lookahead` is `NULL`, and thus that it will not be dereferenced:
+
+	```
+	/* also store char in lookahead buffer */
+	if (buf_defined(&la))
+	{
+	buf_write_u8(&la, c);
+	if (!isprint(c) && !isspace(c)) /* not ascii? */
+	{
+	if (verbose)
+	{
+	msg(D_LINK_ERRORS | M_ERRNO, "recv_line: Non-ASCII
+	character (%d) read on recv()", (int)c);
+	}
+	*lookahead = la;
+	return false;
+	}
+	}
+	```
+
+	We do think, though, that the code path is not easy to follow and should be improved.
+
+	### OVPN-05: Possible allocation of zero bytes with malloc
+
+	The issue itself is very minor and very unlikely to cause problems. This piece of code can, however, definitely use some improving - which we'll tackle later.
+
+	### OVPN-06: Remove workaround to support obsolete versions of OpenSSL (v0.9.6b)
+
+	This has been fixed by commit "Require minimum OpenSSL 1.0.1" (039a89c331) in the Git master branch.
+
+	### OVPN-07: Remove system() from sample authentication plugin
+
+	A pending patch, "plugins: Replace defer/simple with an improved replacement", refactors the sample plugin code and gets rid of the code patch described in there report. This patch also covers OVPN-04-2.
+
+	### OVPN-08: OpenVPN configuration risks
+
+	#### OVPN-08-1: OpenVPN configuration risks: --script-security 3
+
+	The report claims the following:
+
+	"The third script security level (--script-security 3) allows passwords to be passed to scripts using environment variables. Unprivileged processes on the same system will be able to access these variables as well. Given that this is unsafe on certain platforms and users are encouraged not to use it, there does not seem to be a good enough reason outside of backwards compatibility to continue supporting this mode. Any feature that requires this level of script security should be rewritten to use safer approaches such as files."
+
+	We are not fully convinced there are any viable attack vectors on how this is used in OpenVPN. We acknowledge that environment variables of a process can be accessed with 'ps' or procfs (/proc/$PID/environ) on Linux. FreeBSD has this information only available via `ps`. However, based on our testing on Linux, FreeBSD, and Windows the environment variables of a process (e.g. a script hook) launched by OpenVPN are only available to other processes that run with the same UID/GID as the OpenVPN process itself.
+
+	We do not consider this a security issue, but we do agree that using files instead of environment variables would be slightly safer as more advanced filesystem ACLs could be used for access control (such as SELinux). But since this feature has been available for a long time in OpenVPN and people depend on it, removing would not be trivial.
+
+	#### OVPN-08-2: OpenVPN configuration risks: --tls-verify
+
+	The `--tls-verify` option allows running a command to verify the X509 name of a pending TLS connection that has otherwise passed all other tests of certification, except the revocation test via --crl-verify, which occurs after `--tls-verify`. The `--tls-verify` option can be used to provide fine-grained access control on the server side in ways where the alternative, `--verify-x509-name`, will not suffice.
+
+	We see `--tls-verify` as primarily a server-side option. It could probably be removed from the client-side without any effect on our users. However, it is not altogether clear what the attack vector would be, so we currently don't have any plans on removing it.
+
+	#### OVPN-08-3: OpenVPN configuration risks: --comp-lzo
+
+	We agree that we should warn users about the risks of using compression on encrypted protocols such as OpenVPN. In OpenVPN 2.4.3, we will warn users about this. In addition to --comp-lzo, we will also warn about --compress.
\	No newline at end of file
/dev/null .. Security Announcements/SWEET32.md
@@ 0,0 1,108 @@
+	# OpenVPN and SWEET32
+
+	Security researchers at INRIA published an attack on 64-bit block ciphers, such as 3DES and Blowfish [^0]. They show that they are able to recover plaintext when the same data is sent often enough, and demonstrate how cross-site scripting vulnerabilities can be exploited to send data of interest frequently enough. This vulnerability affects HTTPS as well as HTTP-over-OpenVPN. For a more detailed explanation, visit [sweet32.info](https://sweet32.info/) [^0].
+
+	## Am I affected?
+
+	This depends on the cipher you've chosen (OpenVPN's `--cipher` option). **OpenVPN's default cipher, BF-CBC, is affected by this attack.**
+
+	You can check if you're affected by installing OpenVPN 2.3.12 [^1] or newer, and running `openvpn --show-ciphers`. This will list which ciphers should no longer be used. For convenience, we provide a summary of commonly used ciphers here:
+
+	Affected ciphers that should no longer be used:
+	- BF-*
+	- DES* (including 3DES variants)
+	- RC2-*
+
+	Ciphers that are *not* affected:
+	- AES-*
+	- CAMELLIA-*
+	- SEED-*
+
+	## Mitigation
+
+	### 1. Change to a larger block cipher
+
+	The best mitigation is to transition away from small-block ciphers. This requires editing the cipher setting in all server and client configs (or upgrading to our experimental branch, see below).
+
+	For currently supported ciphers, OpenVPN recommends using AES-256-CBC or AES-128-CBC. OpenVPN 2.4 and newer will also support GCM. For 2.4+, we recommend using AES-256-GCM or AES-128-GCM.
+
+	### 2. Renegotiate more often
+
+	If changing the cipher is not possible, for example, because you do not control the server or cannot update all client configs quickly, you can renegotiate new keys more frequently. For instance, add `--reneg-bytes 64000000` to your config to renegotiate after every 64 megabytes.
+
+	If you're using two-factor authentication or username-password authentication, this might require users to re-enter their 2FA token or username and password. To avoid this, do not use `--auth-nocache`, and use the `auth-token` option (see below) in the client-connect and auth-user-pass-verify scripts on the server side to request 2FA only once per session.
+
+	The (undocumented) `auth-token` option can be pushed by a client-connect script (running on the server) to instruct the connecting client to return this token as the password during the next authentication. The auth-user-pass-verify script (running on the server) should accept this token during subsequent authentication sessions until the token expires.
+
+	The following client-connect and auth-user-pass-verify scripts illustrate how these options can be used. **These scripts should not be used as-is!** They are examples only and should be adapted to your specific needs.
+
+	```python
+	#!/usr/bin/env python
+	# client-connect script
+	import base64
+	import hmac
+	import os
+	import sys
+	import time
+
+	username = os.environ['username']
+
+	ts = time.time()
+	to_auth = str(ts) + ":" + username
+
+	h = hmac.new('mysecret')
+	h.update(to_auth)
+	digest = base64.b64encode(h.digest())
+
+	auth_token = "push \"auth-token " + str(ts) + ":" + digest + "\""
+
+	print("Sending auth-token:", auth_token)
+
+	open(sys.argv[1], 'w').write(auth_token)
+	```
+
+	```python
+	#!/usr/bin/env python
+	# auth-user-pass-verify script
+	import base64
+	import hmac
+	import os
+	import time
+
+	username = os.environ['username']
+	password = os.environ['password']
+
+	if (password == "mysecretpassword"):
+	print("password OK")
+	exit(0)
+
+	token = password.split(":")
+
+	to_auth = token[0] + ":" + os.environ['username']
+
+	h = hmac.new('mysecret')
+	h.update(to_auth)
+	digest = h.digest()
+
+	if digest != base64.b64decode(token[1]):
+	print("Auth-token incorrect")
+	exit(1)
+
+	if time.time() - float(token[0]) > 60:
+	print("Auth-token expired")
+	exit(1)
+
+	exit(0)
+	```
+
+	### 3. Cipher negotiation (OpenVPN 2.4 and newer)
+
+	OpenVPN 2.4 and newer support cipher negotiation. If both peers (client and server) support cipher negotiation, OpenVPN will default to using AES-GCM.
+
+	For more details, see the OpenVPN 2.4 man page on `ncp-ciphers`.
+
+	## References
+
+	[^0]: [sweet32.info](https://sweet32.info/)
+	[^1]: [OpenVPN Downloads](https://openvpn.net/index.php/open-source/downloads.html)
+	[^2]: [OpenVPN GitHub](https://github.com/OpenVPN/openvpn.git)
\	No newline at end of file
/dev/null .. Security Announcements/SecurityAnnouncement-97597e732b.md
@@ 0,0 1,31 @@
+	# Introduction
+
+	In late November 2014, Dragana Damjanovic notified OpenVPN developers of a critical *denial of service* security vulnerability (CVE-2014-8104). The vulnerability allows a *tls-authenticated client* to crash the server by sending a too-short control channel packet to the server. This vulnerability is denial of service only.
+
+	A fixed version of OpenVPN (2.3.6) was released on December 1st, 2014 at around 18:00 UTC. The fix was also backported to the OpenVPN 2.2 branch and released in OpenVPN 2.2.3, a source-only release.
+
+	## Scope of the Vulnerability
+
+	This vulnerability affects all OpenVPN 2.x versions released since 2005. It is also possible that older versions might be affected. However, only *server availability* is affected. Confidentiality and authenticity of traffic are *not* affected.
+
+	The OpenVPN 3.x codebase used in most OpenVPN Connect clients (Android, iOS) is not vulnerable and is not used on the server-side.
+
+	## Mitigating Factors
+
+	Only *tls-authenticated* clients can trigger the vulnerability in the OpenVPN server. Thus both client certificates and TLS auth will protect against this exploit as long as all OpenVPN clients can be trusted to not be compromised and/or malicious. It should be noted that username/password authentication does *not* protect against this exploit, and servers using `--client-cert-not-required` by definition have no client certificates to protect against this exploit.
+
+	VPN service providers are particularly affected because anyone can obtain the necessary client certificates and TLS auth keys.
+
+	## Has OpenVPN Been Successfully Exploited?
+
+	An OpenVPN server can be easily exploited (crashed) using this vulnerability by an authenticated client. However, there are no reports of this exploit being used in the wild before the release of the fixed version (2.3.6).
+
+	## How Do I Fix This?
+
+	Simply install a patched version of OpenVPN. If you're using official releases, go for OpenVPN 2.3.6 or the latest Git "master". If you're using OpenVPN from your operating system's software repositories, install an updated version from them.
+
+	If you're maintaining packages based on OpenVPN 2.2, you can obtain a backported patch from the Git repository's release/2.2 branch.
+
+	## Is Access Server Affected?
+
+	Access Server versions prior to 2.0.11 are vulnerable. The first fixed, non-vulnerable version is 2.0.11 - you should upgrade to it as soon as possible, especially if you suspect some clients might be malicious.
\	No newline at end of file
/dev/null .. Security Announcements/SecurityAnnouncement-FREAK.md
@@ 0,0 1,10 @@
+	The OpenSSL versions included in the official OpenVPN *Windows installers* before 2.3.6-I002/I602 are vulnerable to [FREAK](https://www.smacktls.com/). All users of the official OpenVPN Windows installers are strongly advised to upgrade their OpenVPN installations or take additional steps (see below) to counter the threat. OpenVPN users on UNIX systems usually receive an updated OpenSSL version through their package management system and do not need to update OpenVPN.
+
+	Thankfully, the vulnerability's impact on OpenVPN is relatively minor:
+
+	- If activated, OpenVPN's `tls-auth` feature blocks this attack.
+	- Adding `!EXP` to the server-side `tls-cipher` is sufficient to prevent attacks. The recommended `tls-cipher` string is `DEFAULT:!EXP:!LOW:!PSK:!SRP:!kRSA`. This configuration excludes export ciphers, weak ciphers (like DES), and RSA key exchange (note: not RSA authentication), while allowing any future, stronger cipher suites.
+	- Clients who want to completely avoid this attack on clients before 2.3.6-I002/I603 can add `!kRSA` to their `tls-cipher` string.
+	- An attacker needs to be in a man-in-the-middle position.
+	- An attacker must invest time and money per OpenVPN instance (restart) to attack a connection, making this mainly relevant for targeted attacks.
+	- OpenVPN consistently offers PFS with its own key exchange mechanism, making it impossible to decrypt sessions before a successful factorization of the temporary export key, even if those connections previously used an RSA_EXPORT cipher.
\	No newline at end of file
/dev/null .. Security Announcements/SecurityAnnouncement-f375aa67cc.md
@@ 0,0 1,13 @@
+	# Exploit Summary
+
+	OpenVPN versions 2.3.0 and earlier, when operating in UDP mode, are susceptible to chosen ciphertext injection due to a comparison function for HMAC that does not execute in constant time. This vulnerability could potentially allow plaintext recovery through a padding oracle attack on the CBC mode cipher used in the cryptographic library. Notably, PolarSSL is affected by this issue; however, the susceptibility of OpenSSL has not been confirmed or tested.
+
+	# Severity
+
+	Typically, OpenVPN servers are configured to silently discard packets that do not have the correct HMAC. Consequently, measuring the processing time for these packets is challenging without a man-in-the-middle (MITM) position. Practically, executing the attack might require specific information about the target.
+
+	The impact of this vulnerability is considered low. The risk heightens significantly if OpenVPN is set up to use a null-cipher, as this configuration could allow arbitrary plaintext injections, thus fully exposing the vulnerability.
+
+	# Affected Versions
+
+	Versions of OpenVPN up to 2.3.0 are affected. A correction for this issue is implemented in OpenVPN 2.3.1 and later versions, as detailed in the [commit f375aa67cc](https://github.com/OpenVPN/openvpn/commit/11d21349a4e7e38a025849479b36ace7c2eec2ee). This vulnerability has been cataloged as CVE-2013-2061.
\	No newline at end of file
/dev/null .. Security Announcements/SecurityAnnouncements.md
@@ 0,0 1,39 @@
+	# Introduction
+
+	This page lists all security announcements made by the OpenVPN project.
+
+	# Announcements
+	- [CVE-2024-28882: OpenVPN in a server role accepts multiple exit notifications from authenticated clients which will extend the validity of a closing session](wiki:CVE-2024-28882) (June 2024)
+	- [CVE-2024-5594: control channel: refuse control channel messages with non-printable characters in them](wiki:CVE-2024-5594) (June 2024)
+	- [CVE-2024-4877: Windows: A malicious process may spoof the interactive service and potentially impersonate a local user](wiki:CVE-2024-4877) (June 2024)
+	- [CVE-2024-27459: Windows: fix a possible stack overflow in the interactive service component which might lead to a local privilege escalation](wiki:CVE-2024-27459) (Mar 2024)
+	- [CVE-2024-24974: Windows: disallow access to the interactive service pipe from remote computers](wiki:CVE-2024-24974) (Mar 2024)
+	- [CVE-2024-27903: Windows: disallow loading of plugins from untrusted installation paths, which could be used to attack openvpn.exe via a malicious plugin](wiki:CVE-2024-27903) (Mar 2024)
+	- [CVE-2024-1305: Windows TAP driver: Fix potential integer overflow in TapSharedSendPacket](wiki:CVE-2024-1305) (Mar 2024)
+	- [CVE-2023-7235: OpenVPN 2.x GUI privilege escalation possible if installed outside default installation path on Windows](wiki:CVE-2023-7235) (Feb 2024)
+	- [CVE-2023-6247: PKCS#7 parser in OpenVPN 3 Core Library can result in NULL-dereference](wiki:CVE-2023-6247) (Feb 2024)
+	- [CVE-2023-46850: Incorrect use of send buffer can cause memory to be sent to peer](wiki:CVE-2023-46850) (Nov 2023)
+	- [CVE-2023-46849: Use of --fragment option can lead to a division by zero error which can be fatal](wiki:CVE-2023-46849) (Nov 2023)
+	- [TunnelCrack: LocalNet and ServerIP attacks on insecure networks](wiki:TunnelCrack) (Oct 2023)
+	- [CVE-2022-0547: Potential authentication by-pass with multiple deferred authentication plug-ins](wiki:CVE-2022-0547)
+	- [CVE-2021-3547: OpenVPN 3 Core library 3.6 and 3.6.1 possible certificate authentication bypass with --verify-x509-name](wiki:CVE-2021-3547)
+	- [CVE-2021-3606: OpenVPN 2.5.2 (Windows only) may load an external OpenSSL configuration file](wiki:CVE-2021-3606)
+	- [CVE-2020-15078: partial information leak upon unauthorized client reconnection](wiki:CVE-2020-15078) (Apr 2021)
+	- [DUHK attack: ANSI X9.31 RNG and Don't Use Hard-coded Keys](wiki:DUHKattack) (Oct 2017)
+	- [Code execution and Privilege escalation problems with NSIS installers](wiki:NSISBug1125) (Sep 2017)
+	- [CVE-2017-12166: out of bounds write in key-method 1](wiki:CVE-2017-12166) (Sep 2017)
+	- [Unquoted service paths in OpenVPN 2.4 Windows installers](wiki:UnquotedServicePathIn24WindowsInstallers)
+	- [Vulnerabilities fixed in OpenVPN 2.3.17 and 2.4.3](wiki:VulnerabilitiesFixedInOpenVPN243) (June 2017)
+	- [Quarkslab and Cryptography Engineering audits](wiki:QuarkslabAndCryptographyEngineerAudits) (May 2017)
+	- [Linux kernel, UDP packets and MSG_PEEK (CVE-2016-10229)](wiki:CVE-2016-10229) (April 2017)
+	- [OpenVPN and SWEET32](wiki:SWEET32) (Aug 2016)
+	- [Tap-windows6 buffer overflow vulnerability](wiki:TapWindows6BufferOverflowVulnerability) (May 2016)
+	- [Vulnerabilities fixed in OpenSSL 1.0.1m](wiki:VulnerabilitiesFixedInOpenSSL1.0.1m) (Mar 2015)
+	- [Security announcement: The FREAK vulnerability](wiki:SecurityAnnouncement-FREAK) (Mar 2015)
+	- [Security announcement: critical denial of service vulnerability (CVE-2014-8104)](wiki:SecurityAnnouncement-97597e732b) (Nov 2014)
+	- [Vulnerabilities fixed in OpenSSL 1.0.1j](wiki:VulnerabilitiesFixedInOpenSSL1.0.1j) (Oct 2014)
+	- [Vulnerabilities fixed in OpenSSL 1.0.1i](wiki:VulnerabilitiesFixedInOpenSSL1.0.1i) (Aug 2014)
+	- [OpenSSL CCS Injection Vulnerability (CVE-2014-0224) and OpenVPN](wiki:CCSInjection) (Jun 2014)
+	- [OpenSSL 'Heartbleed' vulnerability and OpenVPN](wiki:heartbleed) (Apr 2014)
+	- [TLS Triple Handshake Vulnerability and OpenVPN](wiki:TLSTripleHandshakeVulnerabilityAndOpenVPN) (Mar 2013)
+	- [Security announcement: use of non-constant-time memcmp in HMAC comparison in openvpn_decrypt (CVE-2013-2061)](wiki:SecurityAnnouncement-f375aa67cc) (Mar 2013)
\	No newline at end of file
/dev/null .. Security Announcements/SecurityOverview.md
@@ 0,0 1,57 @@
+	# OpenVPN Cryptographic Layer
+
+	This document provides a technical overview of the cryptographic layer of OpenVPN, assuming a prior understanding of modern cryptographic concepts. For more details on security aspects related to OpenVPN, refer to [this FAQ item](wiki/295-are-there-any-known-security-vulnerabilities-with-openvpn).
+
+	## Authentication Modes in OpenVPN
+
+	OpenVPN supports two modes of authentication:
+	- **Static Key**: Utilizes a pre-shared static key.
+	- **TLS**: Employs SSL/TLS along with certificates for authentication and key exchange.
+
+	### Static Key Mode
+	In this mode, a pre-shared key is created and distributed between the OpenVPN peers before establishing the tunnel. The static key comprises four independent keys:
+	- HMAC send
+	- HMAC receive
+	- Encrypt
+	- Decrypt
+
+	By default, the same HMAC key and encryption/decryption key are used by both hosts in static key mode. However, the `--secret` directive with the direction parameter allows utilizing all four keys independently.
+
+	### TLS Mode
+	An SSL session with bidirectional authentication is initiated, requiring each connection side to present a valid certificate. Upon successful SSL/TLS authentication, key materials for encryption/decryption and HMAC are randomly generated using OpenSSL's `RAND_bytes` function and exchanged over the SSL/TLS connection. Each connection side contributes random material, ensuring unique keys for send HMAC, receive HMAC, packet encryption, and packet decryption. Depending on the `--key-method` used (1 or 2), keys are derived either directly from the `RAND_bytes` function or using the TLS PRF function. Starting from OpenVPN 1.5.0, `--key-method 2` is available and will become the default in OpenVPN 2.0.
+
+	SSL/TLS rekeying includes a `transition-window` parameter allowing key overlap during renegotiations, avoiding latency issues.
+
+	To operate over a reliable transport, OpenVPN adds a reliable transport layer atop UDP, as shown in the diagram below.
+
+	### Tunnel Operation
+	Once each peer has its keys, tunnel forwarding begins. The packet structure is as follows:
+
+	```
+	HMAC(explicit IV, encrypted envelope)
+	Explicit IV
+	Encrypted Envelope
+	```
+
+	The plaintext inside the encrypted envelope is structured as:
+
+	```
+	64-bit sequence number
+	Payload data (e.g., IP packet or Ethernet frame)
+	```
+
+	The HMAC and explicit IV are not included within the encrypted envelope.
+
+	The per-packet IV is randomized using a nonce-based PRNG, initially seeded by the OpenSSL `RAND_bytes` function.
+
+	OpenSSL's EVP interface provides HMAC, encryption, and decryption functions, allowing selection of any cipher, key size, and HMAC digest. BlowFish and SHA1 are the default cipher and message digest, respectively. The EVP interface also handles PKCS#5 padding.
+
+	An important security feature in OpenVPN is the `--tls-auth` directive, which uses a pre-shared passphrase or static key to generate an HMAC key for authenticating packets in the TLS handshake sequence, enhancing protection against buffer overflows in OpenSSL's TLS implementation.
+
+	OpenVPN multiplexes the SSL/TLS session for authentication and key exchange with the encrypted tunnel data stream, ensuring SSL/TLS sees a reliable transport layer, while the IP packet forwarder sees an unreliable one. This independence between the reliability and authentication layers is crucial for efficient and secure data transmission.
+
+	## OpenVPN Protocol
+
+	The OpenVPN protocol defines a series of packet types and operations essential for establishing and maintaining a secure VPN tunnel. This includes various message types like `P_CONTROL`, `P_ACK`, and `P_DATA`, each serving specific roles in the communication process. The protocol ensures data integrity, replay protection, and seamless transition during key renegotiations, leveraging HMAC signatures and TLS sessions authenticated and initialized as described.
+
+	[Protocol details and packet formats are extensively documented in the source code, specifically in `ssl.h` within the OpenVPN repository.]
\	No newline at end of file
/dev/null .. Security Announcements/SecurityVulnerabilities.md
@@ 0,0 1,7 @@
+	# Reporting security vulnerabilities
+
+	If you discover a security vulnerability in OpenVPN's [open source projects](https://github.com/OpenVPN), please send an email to [security@openvpn.net](mailto:security@openvpn.net).
+
+	# How we handle security issues
+
+	The basic goals were defined in the IRC meeting on [15th July 2010](http://thread.gmane.org/gmane.network.openvpn.devel/3841). We attempt to disclose security issues in 3 weeks - or less if a fix is ready. If a fix is not ready in 3 weeks the issue should be disclosed nevertheless and provide workarounds (if any) to users and then fix the issue as soon as possible. Also, **all** security issues - whether they're theoretical or being exploited - should be fixed. All our users should also be informed about vulnerabilities in external software OpenVPN depends on (e.g., OpenSSL). This will be done after developers of the external software have already disclosed the vulnerability.
\	No newline at end of file
/dev/null .. Security Announcements/TLSTripleHandshakeVulnerabilityAndOpenVPN.md
@@ 0,0 1,34 @@
+	People often inquire about the "TLS Triple Handshake Vulnerability." OpenVPN is not affected, as explained in the following excerpt from [this email thread](http://thread.gmane.org/gmane.network.openvpn.devel/8341):
+
+	```
+	1- Does OpenVPN use a lightweight SSL handshake upon automatic reconnection?
+
+	No. OpenVPN does not initiate TLS session renegotiation or resumption.
+	The renegotiation messages in OpenVPN connection logs relate to OpenVPN's data-session key renegotiations, which are not affected by this attack. For OpenVPN's control channel, it heavily depends on the underlying crypto library, either OpenSSL or PolarSSL.
+
+	The OpenSSL builds of OpenVPN might respond to session renegotiations initiated by a malicious server, but it's not completely clear on OpenSSL's behavior. It is not certain whether a MITM-initiated renegotiation is enough to mount the secure-resumption attack.
+
+	The PolarSSL builds of OpenVPN have session renegotiation disabled and will not participate in session renegotiation at all. These are thus not affected.
+
+	Based on discussions with Dr. Stephen Henson of the OpenSSL project, OpenVPN (when built with OpenSSL) is protected from the Triple Handshake attack because it declares a verification callback method that verifies the peer certificate.
+
+	The Triple Handshake attack can only succeed if the attacker is able to force a mid-session certificate change that bypasses certificate and identity verification on the client.
+
+	But because OpenVPN declares a verification callback:
+
+	SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, verify_callback);
+
+	and because the OpenVPN verification callback always returns a failure status if peer certificate verification fails, it means that the attack could only succeed if the attacker has a cert and private key already trusted by the client, i.e., the server cert was signed by the CA declared in the client config file, and trusted by other identity checks required by the client config (such as tls-remote, remote-cert-tls, ns-cert-type, etc.). But if this were the case, then the client would already be vulnerable to MiTM attacks, even in the absence of the Triple Handshake attack.
+
+	So given that (a) the verify callback is always called on the client when the server presents a certificate, and (b) the verify callback cannot be bypassed by a mid-session certificate change operation initiated by the server, I think we are safe for now.
+
+	2- If so, when does OpenVPN do a full handshake vs. lightweight (abbreviated) handshake?
+
+	See above.
+
+	OpenVPN doesn't rely on SSL/TLS renegotiation and always does a full handshake from scratch when renegotiating.
+
+	3- Does it renegotiate the master key upon reconnection?
+
+	On any TLS errors reported by OpenSSL, OpenVPN shuts down the previous TLS session and starts a new session from scratch. It relies on OpenSSL to do the master key renegotiation.
+	```
/dev/null .. Security Announcements/TapWindows6BufferOverflowVulnerability.md
@@ 0,0 1,3 @@
+	There was a buffer overflow vulnerability in tap-windows6 version 9.21.1, in `adapter.c`, where the code was failing to check the size of a registry string read by `NdisReadConfiguration` before copying it to a fixed length buffer. The vulnerability could potentially allow arbitrary code execution in the kernel context of a signed driver, however it requires local Admin privileges to exploit. Further details are available in the [reporter's GitHub repository](https://github.com/Rootkitsmm/OpenVpn-Pool-Overflow/blob/master/README.md).
+
+	This problem has been fixed in tap-windows6 version 9.21.2, which is bundled with `openvpn-install-2.3.10-I604` and later. The I00x installers do not have this vulnerability, because they bundle the old NDIS 5-based tap-windows driver. The source code for the fix is [available on GitHub](https://github.com/mattock/tap-windows6/commit/6b05a00fb85903f0d26cb3a21bb70b1f814003d5).
\	No newline at end of file
/dev/null .. Security Announcements/TunnelCrack.md
@@ 0,0 1,21 @@
+	# Statement regarding TunnelCrack vulnerabilities
+
+	## Background
+
+	In the recent findings collectively named TunnelCrack, Mathy Vanhoef et al highlight shortcomings in the IP networking stack that affect VPNs. For details, visit [TunnelCrack](https://tunnelcrack.mathyvanhoef.com/). These shortcomings are not unique to OpenVPN; they are inherent to routing-based VPN solutions in general.
+
+	The basic premise of the LocalNet vulnerability concerns the local network address being manipulated by an attacker, presenting the possibility of traffic inadvertently bypassing the VPN. The ServerIP vulnerability is an attack allowing traffic intended for a specific IP address to bypass the VPN.
+
+	On most networks, you won't experience problems. However, issues may arise on untrusted networks, particularly those where malicious actors can control the local DHCP server or router or when using an untrusted DNS resolver.
+
+	## Mitigation
+
+	OpenVPN does support the **block-local** flag to the **--redirect-gateway** and **--redirect-private** options to mitigate the problem by routing the local network IPs into the VPN tunnel. In its current implementation, it is, however, not completely effective in protecting against all possible LocalNet attacks.
+
+	OpenVPN apps on Android are not affected by these vulnerabilities. However, other supported platforms leave room for sufficiently sophisticated attacks.
+
+	The OpenVPN community is committed to ensuring that VPN users stay safe even on untrusted networks. We are therefore working on implementing mitigations on the client side to resolve these issues. These mitigations will aim to ensure traffic stays within the VPN context and does not leak outside of it. Due to differences in operating systems and how they handle certain aspects of IP networking, the mitigations may be implemented differently on the different platforms but achieve the same goal. Currently, the idea is to ensure that the "block-local" flag will really block any local networks on all platforms.
+
+	## Note regarding TunnelVision
+
+	TunnelVision leverages DHCP using option 121 to push routes to client computers. This can lead to traffic being guided away from the VPN. It is very similar to what happens with TunnelCrack.
\	No newline at end of file
/dev/null .. Security Announcements/UnquotedServicePathIn24WindowsInstallers.md
@@ 0,0 1,36 @@
+	# Introduction
+
+	Commit [8795ccfd25](https://github.com/OpenVPN/openvpn-build/commit/8795ccfd251b8252122dec43e6327a74856d17db) to openvpn-build made the NSIS installer manage services using SimpleSC NSIS plugin. The new service management commands did not properly quote service paths which created a subtle medium-level vulnerability. The vulnerability can be exploited if two conditions are met:
+
+	- The C:\ drive is writable by limited user(s)
+	- OpenVPN was installed using official **OpenVPN 2.4** Windows installers
+
+	Users of such systems are urged to upgrade to openvpn-install-2.4.3-I602 or later as soon as possible.
+
+	Thanks to Jason Haar for finding and reporting this issue! The original Nessus report is available below.
+
+	# Original Nessus report
+
+	## Description
+
+	The remote Windows host has at least one service installed that uses an unquoted service path, which contains at least one whitespace. A local attacker can gain elevated privileges by inserting an executable file in the path of the affected service.
+
+	Note that this is a generic test that will flag any application affected by the described vulnerability.
+
+	## Solution
+
+	Ensure that any services that contain a space in the path enclose the path in quotes.
+
+	## See Also
+
+	- [Nessus Reference](http://www.nessus.org/u?84a4cc1c)
+	- [CWE-428](http://cwe.mitre.org/data/definitions/428.html)
+	- [Common Exploits on Unquoted Service Paths](https://www.commonexploits.com/unquoted-service-paths/)
+	- [Nessus Documentation](http://www.nessus.org/u?4aa6acbc)
+
+	## Output
+
+	Nessus found the following services with an untrusted path:
+
+	- OpenVPNServiceLegacy: `C:\Program Files\OpenVPN\bin\openvpnserv.exe`
+	- OpenVPNServiceInteractive: `C:\Program Files\OpenVPN\bin\openvpnserv.exe`
\	No newline at end of file
/dev/null .. Security Announcements/VulnerabilitiesFixedInOpenSSL1.0.1i.md
@@ 0,0 1,21 @@
+	# Background
+
+	On August 6, 2014, the OpenSSL project released version 1.0.1i, which addressed [several security vulnerabilities](http://www.openssl.org/news/secadv_20140806.txt) classified as moderate severity or less. These updates were crucial as official OpenVPN Windows installers include OpenSSL 1.0.1, necessitating a [new Windows installer release](http://openvpn.net/index.php/download/community-downloads.html) by the OpenVPN project. On UNIX-based operating systems, upgrading OpenSSL is typically managed by the OS provider.
+
+	# List of Vulnerabilities
+
+	| **Vulnerability Name** | **ID** | **Affects OpenVPN?** |
+	|-------------------------------------------------------------|--------------|----------------------|
+	| Information leak in pretty printing functions | CVE-2014-3508| Possibly[1]. |
+	| Crash with SRP ciphersuite in Server Hello message | CVE-2014-5139| No. OpenVPN does not use SRP. |
+	| Race condition in ssl_parse_serverhello_tlsext | CVE-2014-3509| No. |
+	| Double Free when processing DTLS packets | CVE-2014-3505| No. OpenVPN does not use DTLS. |
+	| DTLS memory exhaustion | CVE-2014-3506| No. OpenVPN does not use DTLS. |
+	| DTLS memory leak from zero-length fragments | CVE-2014-3507| No. OpenVPN does not use DTLS. |
+	| OpenSSL DTLS anonymous EC(DH) denial of service | CVE-2014-3510| No. OpenVPN does not use DTLS. |
+	| OpenSSL TLS protocol downgrade attack | CVE-2014-3511| No. OpenVPN already defaults to TLS 1.0 [2]. |
+	| SRP buffer overrun | CVE-2014-3512| No. OpenVPN does not use SRP. |
+
+	[1] This vulnerability does not directly affect OpenVPN. While leaked information is not transmitted to peers by OpenVPN, it might be possible that this information is passed on to a client script or plugin. The form of the leaked information and whether it is exported beyond a NULL-byte is uncertain. Such a plugin/script could potentially leak the information to an attacker.
+
+	[2] If you are using OpenVPN 2.3.3 or OpenVPN 2.3.4 and have enabled newer TLS versions by using the `tls-version-min` option in your configuration, your setup is susceptible to the protocol downgrade attack. Nonetheless, it remains at least as secure as a configuration without the `tls-version-min` option.
\	No newline at end of file
/dev/null .. Security Announcements/VulnerabilitiesFixedInOpenSSL1.0.1j.md
@@ 0,0 1,16 @@
+	# Background
+
+	On 15th Oct 2014, the OpenSSL project released version 1.0.1j that addressed [several security vulnerabilities](http://www.openssl.org/news/secadv_20141015.txt) of high severity or less. Official OpenVPN Windows installers bundle OpenSSL 1.0.1, necessitating a [new Windows installer release (I004/I604)](http://openvpn.net/index.php/download/community-downloads.html) by the OpenVPN project. On *NIX-based operating systems, OpenSSL is typically dynamically linked to OpenVPN, and the OS provider manages OpenSSL upgrades.
+
+	# List of vulnerabilities
+
+	| **Vulnerability name** | **ID** | **Affects OpenVPN?** | **Mitigation** |
+	|---------------------------------|----------------|----------------------|----------------|
+	| SRTP Memory Leak | CVE-2014-3513 | Denial-of-service only | TLS auth can[^1] protect against this vulnerability |
+	| Session Ticket Memory Leak | CVE-2014-3567 | Denial-of-service only | TLS auth can[^1] protect against this vulnerability |
+	| SSL 3.0 Fallback protection | CVE-2014-3568 | No SSLv3 in OpenVPN, not affected | N/A |
+	| Build option no-ssl3 is incomplete | - | No SSLv3 in OpenVPN, not affected | N/A |
+
+	Analysis of the impact of these vulnerabilities is taken from [here](http://thread.gmane.org/gmane.network.openvpn.devel/9133/focus=9139).
+
+	[^1]: The amount of protection is limited in environments where the TLS auth key is widely distributed (large organizations) or public (VPN service providers).
\	No newline at end of file
/dev/null .. Security Announcements/VulnerabilitiesFixedInOpenSSL1.0.1m.md
@@ 0,0 1,40 @@
+	# Introduction
+
+	On 19th March 2015, the OpenSSL project released updates that [fixed a number of security vulnerabilities](https://www.openssl.org/news/secadv_20150319.txt). This page discusses the impact of those vulnerabilities on OpenVPN. The content on this page is largely sourced from an [email thread](http://thread.gmane.org/gmane.network.openvpn.user/35653) on the openvpn-user mailing list (thanks Steffan!).
+
+	# Vulnerabilities that may affect OpenVPN
+
+	Depending on your configuration and the OpenSSL version used, the following advisories from the list can apply to OpenVPN setups:
+
+	- Reclassified: RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204)
+	- Segmentation fault in ASN1_TYPE_cmp (CVE-2015-0286)
+	- ASN.1 structure reuse memory corruption (CVE-2015-0287)
+	- Base64 decode (CVE-2015-0292)
+	- Use After Free following d2i_ECPrivatekey error (CVE-2015-0209)
+	- OpenVPN 2.3, the current version, does not support EC certs yet. Note, however, that the git master branch *does*.
+
+	The following vulnerabilities affect OpenSSL 1.0.2 only, which is quite new and not yet used very often. Furthermore, the official OpenVPN Windows installers bundle OpenSSL 1.0.1, which is not vulnerable:
+
+	- Multiblock corrupted pointer (CVE-2015-0290)
+	- OpenSSL 1.0.2 !ClientHello sigalgs DoS (CVE-2015-0291)
+	- Segmentation fault for invalid PSS parameters (CVE-2015-0208)
+	- Empty CKE with client auth and DHE (CVE-2015-1787)
+
+	# Vulnerabilities that do not affect OpenVPN
+
+	The following do *not* apply to OpenVPN:
+
+	- Segmentation fault in DTLSv1_listen (CVE-2015-0207)
+	- OpenVPN does not use DTLS
+	- PKCS7 NULL pointer dereferences (CVE-2015-0289)
+	- TLS does not use PKCS#7
+	- DoS via reachable assert in SSLv2 servers (CVE-2015-0293)
+	- OpenVPN only supports TLSv1.0+
+	- Handshake with unseeded PRNG (CVE-2015-0285)
+	- OpenVPN manually seeds the PRNG
+	- X509_to_X509_REQ NULL pointer deref (CVE-2015-0288)
+	- Neither OpenVPN nor the OpenSSL ssl functions call X509_to_X509_REQ()
+
+	# Mitigating factors
+
+	The use of TLS auth keys offers good protection against these vulnerabilities.
\	No newline at end of file
/dev/null .. Security Announcements/VulnerabilitiesFixedInOpenVPN243.md
@@ 0,0 1,99 @@
+	# Introduction
+
+	In May/June 2017 Guido Vranken threw a fuzzer at OpenVPN 2.4.2. In the process, he found several vulnerabilities and reported them to the OpenVPN project. The OpenVPN Git branches were patched as follows:
+
+	- master: 7 patches
+	- release/2.4: 7 patches
+	- release/2.3: 5 patches (no mbedtls patches)
+	- release/2.2: 1 patch (only the NTLM patch)
+
+	The first releases to have these fixes are OpenVPN 2.4.3 and 2.3.17. These releases also include a bunch of fixes not related to Guido's findings.
+
+	**PLEASE NOTE** We have noticed that the Cloudflare front has been serving out the wrong contents for several users. See [this page](wiki:release-packages-2.4.3-2.3.17) for more information.
+
+	# Vulnerabilities
+
+	## Remotely-triggerable ASSERT() on malformed IPv6 packet
+
+	This vulnerability is of serious nature: it can be used to remotely shutdown an OpenVPN server or client if IPv6 and `--mssfix` are enabled and the IPv6 networks used inside the VPN are known.
+
+	This issue was found by Guido Vranken and has been assigned CVE-2017-7508. It has been fixed in commit "Fix remotely-triggerable ASSERT() on malformed IPv6 packet":
+
+	- master: c3f47077a7
+	- release/2.4: ed28cde3d8
+	- release/2.3: fc61d1bda1
+
+	## Pre-authentication remote crash/information disclosure for clients
+
+	If clients use an HTTP proxy with NTLM authentication (i.e. `--http-proxy <server> <port> [<authfile>|'auto'|'auto-nct'] ntlm2`), a man-in-the-middle attacker between the client and the proxy can cause the client to crash or disclose at most 96 bytes of stack memory. The disclosed stack memory is likely to contain the proxy password.
+
+	If the proxy password is not reused, this is unlikely to compromise the security of the OpenVPN tunnel itself. Clients who do not use the `--http-proxy` option with ntlm2 authentication are not affected.
+
+	This issue has been assigned CVE-2017-7520. It has been fixed in commit "Prevent two kinds of stack buffer OOB reads and a crash for invalid input data":
+
+	- master: 7718c8984f
+	- release/2.4: 043fe32787
+	- release/2.3: f38a4a1059
+	- release/2.2: 4bec9d25d5
+
+	## Potential double-free in --x509-alt-username
+
+	OpenVPN did not check the return value of `ASN1_STRING_to_UTF8()` in `extract_x509_extension()`. Ignoring such a failure could result in `buf` being free'd twice. An error in `ASN1_STRING_to_UTF8()` can be caused remotely if the peer can make the local process run out of memory.
+
+	The problem can only be triggered for configurations that use the `--x509-alt-username` option with an x509 extension (i.e. the option parameter starts with "ext:"). Extensive testing by Guido Vranken gives confidence that this function is very unlikely to fail in real-world usage (using subjectAltName or issuerAltName extensions) for other reasons than memory exhaustion.
+
+	This issue was found by Guido Vranken and has been assigned CVE-2017-7521. It has been fixed in commit "Fix potential double-free in --x509-alt-username (CVE-2017-7521)":
+
+	- master: cb4e35ece4
+	- release/2.4: 0400840671
+	- release/2.3: 1dde0cd6e5
+
+	## Remote-triggerable memory leaks
+
+	Several of our OpenSSL-specific certificate-parsing code paths did not always clear all allocated memory. Since a client can cause a few bytes of memory to be leaked for each connection attempt, a client can cause a server to run out of memory and thereby kill the server. That makes this a (quite inefficient) DoS attack.
+
+	In particular, when using the `--x509-alt-username` option on OpenSSL builds with an extension (argument prefixed with "ext:", e.g. "ext:subjectAltName"), the code would not free all allocated memory.
+
+	This issue was found by Guido Vranken and has been assigned CVE-2017-7521. It has been fixed in commit "Fix remote-triggerable memory leaks (CVE-2017-7521)":
+
+	- master: 2d032c7fcd
+	- release/2.4: 2341f71619
+	- release/2.3: 84e1775961
+
+	## Post-authentication remote DoS when using the --x509-track option
+
+	`asn1_buf_to_c_string()` returned a literal string if the input ASN.1 string contained a NUL character, while the caller expects a mutable string. The caller will attempt to change this string, which allows a client to crash a server by sending a certificate with an embedded NUL character.
+
+	The other way around is not interesting, as servers are allowed to stop a client by design.
+
+	Impact analysis:
+	- applies to mbedtls builds only
+	- introduced in 2.4 (so 2.3 is not affected)
+	- can only be exploited if the `--x509-track` option is used
+	- requires the CA to sign a certificate with an embedded NUL in the certificate subject
+
+	This issue was found by Guido Vranken and has been assigned CVE-2017-7522. It has been fixed in commit "mbedtls: fix --x509-track post-authentication remote DoS (CVE-2017-7522)":
+
+	- master: 426392940c
+	- release/2.4: 67edada0be
+
+	## Null-pointer dereference in establish_http_proxy_passthru()
+
+	Client could crash if the peer did not specify the 'realm' and/or 'nonce' values. These pointers are dereferenced in `DigestCalcHA1()` and `DigestCalcResponse();` hence, if not set, a null-pointer dereference would occur.
+
+	This problem has been fixed in commit "Fix a null-pointer dereference in establish_http_proxy_passthru()":
+
+	- master: 14865773ad
+	- release/2.4: bf547b8ac7
+	- release/2.3: 479b6d13d8
+
+	# Issues with little to no practical security impact
+
+	Many of the findings were such that they don't have a practical security impact. Nevertheless, they are bugs and were fixed in the following Git commits:
+
+	- Restrict `--x509-alt-username` extension types
+	- Fix potential 1-byte overread in TCP option parsing
+	- Fix mbedtls fingerprint calculation
+	- openssl: fix overflow check for long `--tls-cipher` option
+	- Ensure option array p[] is always NULL-terminated
+	- Pass correct buffer size to `GetModuleFileNameW()` (Quarkslabs finding 5.6)
\	No newline at end of file
/dev/null .. Security Announcements/heartbleed.md
@@ 0,0 1,70 @@
+	# OpenSSL Vulnerability - Heartbleed
+
+	A vulnerability in OpenSSL, nicknamed Heartbleed, was published in April 2014 [[1]](http://heartbleed.com/). OpenVPN uses OpenSSL as its crypto library by default and thus is affected too.
+
+	## What does this mean?
+	An attacker can trick OpenSSL into returning a part of your program memory. That memory contains your session keys (the keys used to encrypt your data), and usually your master secret key too. If your OpenVPN is or has been vulnerable to Heartbleed you should consider your keys, and the traffic over the VPN tunnel, compromised.
+
+	## Am I affected too?
+	Your OpenVPN is affected when your OpenVPN is linked against OpenSSL, versions 1.0.1 through 1.0.1f.
+
+	## Has OpenVPN been successfully exploited?
+	This is very likely. On 16th April 2014, a mail was sent to the openvpn-user list by Fredrik Strömberg, who claimed the following:
+
+	```
+	We have successfully extracted private key material multiple times
+	from an OpenVPN server by exploiting the Heartbleed Bug. The material
+	we found was sufficient for us to recreate the private key and
+	impersonate the server.
+
+	--- snip ---
+
+	... you should assume that other teams with more nefarious purposes
+	have already created weaponized exploits for OpenVPN. Just to be
+	clear, we don't intend to use this exploit ourselves. We merely
+	developed it to examine the practical impact on OpenVPN as part of
+	our incident investigation.
+	```
+
+	More details in the [email thread](http://thread.gmane.org/gmane.network.openvpn.user/34784). The exploit has not yet been tested by anyone within the OpenVPN project, but we have to assume it is capable of doing what Fredrik claims.
+
+	## How do I fix this?
+	1. Update your OpenSSL library
+	2. Revoke your old private keys
+	3. Generate new private keys
+	4. Create certificates for the new private keys
+
+	## Is this for clients or servers?
+	Both. Replace the keys for each peer that was active while linked against a vulnerable OpenSSL.
+
+	## Are Android clients affected too?
+	Android shipped OpenSSL 1.0.1 as of 4.1, but disabled heartbeats since 4.1.2. That means only Android 4.1(.0) and 4.1.1 are vulnerable. There are apps available to check your own device like [Heartbleed Detector](https://play.google.com/store/apps/details?id=com.lookout.heartbleeddetector).
+
+	OpenVPN for Android 0.6.17 and later use an embedded not vulnerable OpenSSL library. OpenVPN Connect uses PolarSSL and is not vulnerable either. This, however, still leaves all other apps/services on the device vulnerable.
+
+	## What about Tunnelblick for MacOS X?
+	Old versions of Tunnelblick are affected, but fixed versions [have been released](https://code.google.com/p/tunnelblick/wiki/News).
+
+	## What about Windows clients?
+	All [official OpenVPN Windows client installers](http://openvpn.net/index.php/download/community-downloads.html) are shipped with OpenSSL. However, only installer versions `2.3-rc2-I001` through `2.3.2-I003` ship a vulnerable version. Installer version `2.3.2-I004` fixes this vulnerability by bundling OpenSSL 1.0.1g. The fixed version can be downloaded from [here](http://openvpn.net/index.php/open-source/downloads.html).
+
+	## Is Access Server affected?
+	Short answer: yes.
+
+	All Access Server users are advised to [upgrade immediately](https://openvpn.net/index.php/access-server/overview.html) to Access Server 2.0.7. If you would like to patch the OpenSSL libraries for older versions of Access Server please [download the libs](http://swupdate.openvpn.org/hb/) for your distro and copy them into `/usr/local/openvpn_as/lib`.
+
+	For more information have a look at the OpenVPN Technologies' [official announcement](http://openvpn.net/index.php/access-server/heartbleed.html).
+
+	## Are OpenVPN Connect clients affected?
+	It depends:
+
+	- The iOS and Android versions use PolarSSL and are not vulnerable
+	- Windows and MacOS X versions use OpenSSL and old client versions are vulnerable
+
+	Access Server 2.0.7 includes OpenVPN Connect clients that have been fixed. If you have installed Access Server 2.0.6 and for whatever reason can't upgrade to 2.0.7 you should get updated clients from [here](http://swupdate.openvpn.org/hb/Clients).
+
+	## Are PolarSSL builds affected too?
+	No. See [[2]](https://polarssl.org/tech-updates/security-advisories/polarssl-security-advisory-2014-01).
+
+	## Do TLS-auth keys protect my setup?
+	To some extent. You are strongly encouraged to use TLS-auth keys. In this scenario, an attacker cannot attack OpenVPN instances without the TLS-auth key. With a large user base, you should however consider the possibility of one (or more) of the OpenVPN instances being compromised. Such a compromised instance could attack other instances (including the server).
\	No newline at end of file
meetups.md .. /dev/null
@@ 1,3 0,0 @@
-	# Meetups
-
-	This is the parent page for community meetups and hackathons.
security-announcements.md .. /dev/null
@@ 1,3 0,0 @@
-	# Security-Announcements
-
-	These pages list all security announcements made by the OpenVPN project.
security-announcements/cve-2024-28882.md .. /dev/null
@@ 1,16 0,0 @@
-	# CVE-2024-28882
-
-	## Summary
-
-	OpenVPN in a server role accepts multiple exit notifications from authenticated clients which will extend the validity of a closing session only call schedule_exit() once (on a given peer).
-
-	## Security scope
-
-	An authenticated client can make the server "keep the session" even when the server has been told to disconnect this client.
-
-	Affected versions: 2.6.0 until 2.6.10 (inclusive)
-
-	## References
-	* Release notes: https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg07634.html
-	* CVE record: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-28882
-	* Reported by: Reynir Björnsson
security-announcements/cve-2024-4877.md .. /dev/null
@@ 1,13 0,0 @@
-	# CVE-2024-4877
-
-	# Description
-
-	Windows: A malicious process may spoof the interactive service and potentially impersonate a local user interactive.c and OpenVPN-GUI for Windows: if an attacker with SeImeprsonatePrivilege manages to create a namedpipe server with a name matching that used by the "Interactive Service", user interfaces such as OpenVPN-GUI connecting to it could allow the attacker to impersonate the user running the UI.
-
-	To address this, we harden the security of the pipe, making it possible only for processes running as SYSTEM (such as the interactive service) create the pipe with the same name. Further, to protect against any such pipes created prior to startup of the service, clients of the service must match the PID of the pipe server with that of the service. This is implemented in OpenVPN-GUI for Windows.
-
-	## References
-
-	* Release notes: https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg07634.html
-	* CVE record: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-4877
-	* Reported by: Zeze with TeamT5 <​zeze7w@gmail.com>
security-announcements/cve-2024-5594.md .. /dev/null
@@ 1,15 0,0 @@
-	# CVE-2024-5594
-
-	## Summary
-
-	Control channel: refuse control channel messages with nonprintable characters in them.
-
-	## Security scope
-
-	A malicious openvpn peer can send garbage to openvpn log, or cause high CPU load.
-
-	## References
-
-	* Release notes: ​https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg07634.html
-	* CVE record: ​https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-5594
-	* Reported by: Reynir Björnsson