Hi,
On Wed, Apr 05, 2017 at 06:34:34AM +0200, Simon Matter wrote:
> I've attached v2 now which works without any config change:
[..]
> I prefer this version as it allows everybody to profit from it without
> touching any config files.
I can see the reasoning, but 25% feels a bit on the high side
Hi,
On 05-04-17 08:57, Gert Doering wrote:
> On Wed, Apr 05, 2017 at 06:34:34AM +0200, Simon Matter wrote:
>> I've attached v2 now which works without any config change:
> [..]
>> I prefer this version as it allows everybody to profit from it without
>> touching any config files.
>
> I can see th
On 04/04/2017 10:48, Steffan Karger wrote:
> Hi,
>
> On 3 April 2017 at 23:14, Selva Nair wrote:
>>
>>
>> On Mon, Apr 3, 2017 at 4:43 PM, David Sommerseth
>> wrote:
>>>
>>> On 03/04/17 16:12, Jan Just Keijser wrote:
Hi Samuli,
On 03/04/17 15:53, Samuli Seppänen wrote:
> On 02/
On 05/04/17 09:31, Steffan Karger wrote:
> Hi,
>
> On 05-04-17 08:57, Gert Doering wrote:
>> On Wed, Apr 05, 2017 at 06:34:34AM +0200, Simon Matter wrote:
>>> I've attached v2 now which works without any config change:
>> [..]
>>> I prefer this version as it allows everybody to profit from it with
> On 05/04/17 09:31, Steffan Karger wrote:
>> Hi,
>>
>> On 05-04-17 08:57, Gert Doering wrote:
>>> On Wed, Apr 05, 2017 at 06:34:34AM +0200, Simon Matter wrote:
I've attached v2 now which works without any config change:
>>> [..]
I prefer this version as it allows everybody to profit from
On 05/04/17 14:36, Simon Matter wrote:
>> On 05/04/17 09:31, Steffan Karger wrote:
>>> Hi,
>>>
>>> On 05-04-17 08:57, Gert Doering wrote:
On Wed, Apr 05, 2017 at 06:34:34AM +0200, Simon Matter wrote:
> I've attached v2 now which works without any config change:
[..]
> I prefer thi
On 05/04/17 05:34, Simon Matter wrote:
>>> Hi,
>>>
>>> On Tue, Apr 04, 2017 at 08:29:49AM +0200, Simon Matter wrote:
Interesting to see that there is zero interest in this patch here.
>>>
>>> This is a misinterpretation.
>>>
>>
>> Hi Gert,
>>
>> Thanks for the explanation, I'll be patient th
On 05/04/17 16:42, debbie10t wrote:
>
>
> On 05/04/17 05:34, Simon Matter wrote:
Hi,
On Tue, Apr 04, 2017 at 08:29:49AM +0200, Simon Matter wrote:
> Interesting to see that there is zero interest in this patch here.
This is a misinterpretation.
>>>
>>> Hi Gert,
>
On 05/04/17 17:53, David Sommerseth wrote:
> On 05/04/17 16:42, debbie10t wrote:
>>
>>
>> On 05/04/17 05:34, Simon Matter wrote:
> Hi,
>
> On Tue, Apr 04, 2017 at 08:29:49AM +0200, Simon Matter wrote:
>> Interesting to see that there is zero interest in this patch here.
>
>
On 05/04/17 16:58, David Sommerseth wrote:
> On 05/04/17 17:53, David Sommerseth wrote:
>> On 05/04/17 16:42, debbie10t wrote:
>>>
>>>
>>> A different approach could be like so:
>>>
>>> --reneg-sec 3600
>>> --reneg-sec-1sttime-rand 1|0 (The name here for detail)
>>
>
> Oh, and in regards to the
would probably be a good idea to enable that.
> As I understand it client and server have 60 min. by default. Whatever is
> configured, the smaller value wins. That means, bad clients can set their
> reneg-sec to very low values and trash the server on the other end. From
> the server side this l
On 05/04/17 17:13, debbie10t wrote:
>
>
> On 05/04/17 16:58, David Sommerseth wrote:
>> On 05/04/17 17:53, David Sommerseth wrote:
>>> On 05/04/17 16:42, debbie10t wrote:
>
A different approach could be like so:
--reneg-sec 3600
--reneg-sec-1sttime-rand 1|0 (The name
>
>
> On 05/04/17 17:13, debbie10t wrote:
>>
>>
>> On 05/04/17 16:58, David Sommerseth wrote:
>>> On 05/04/17 17:53, David Sommerseth wrote:
On 05/04/17 16:42, debbie10t wrote:
>
>>
>
> A different approach could be like so:
>
> --reneg-sec 3600
> --reneg-sec-1sttime-ra
>>
>> Where RAND indicates that the first-run timer should run from a random
>> integer from 1 upto the value of --reneg-sec. RAND does not require a
>> user to specify an amount.
>
> But then, why not just do it always and forget about the additional option?
>
Optional option does not mean th
On 05/04/17 18:13, Arne Schwabe wrote:
>
>>>
>>> Where RAND indicates that the first-run timer should run from a random
>>> integer from 1 upto the value of --reneg-sec. RAND does not require a
>>> user to specify an amount.
>>
>> But then, why not just do it always and forget about the addition
Hi,
On Wed, Apr 05, 2017 at 07:00:54PM +0100, debbie10t wrote:
> > Optional option does not mean that it is disabled by default. If you
> > don't the randomness you would need to do:
> >
> > reneg-sec 3600 3600
> >
> > the optional argument also allows it to fine tune it to your needs.
>
> As the
On 05/04/17 21:42, Gert Doering wrote:
> Hi,
>
> On Wed, Apr 05, 2017 at 07:00:54PM +0100, debbie10t wrote:
>>> Optional option does not mean that it is disabled by default. If you
>>> don't the randomness you would need to do:
>>>
>>> reneg-sec 3600 3600
>>>
>>> the optional argument also allows
On 05/04/17 22:42, Gert Doering wrote:
> Following Arne's argument about users and percent math, it might
> indeed be better to have "min max" here ("3500 3600"), because that is
> really easy to understand and explain.
I agree to Arne's approach, using only min/max values instead of a
percentage
On 05/04/17 23:13, debbie10t wrote:
> I don't believe there is any need to specify "max" because that would be
> --reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec
I think you, probably without being aware of it, are agreeing to what
the current proposal is:
--reneg-sec max
hello!
just curious how renegotiation is handled in "https" ?
is it "an abbrevated ssl handshake" (RFC 2246) or ... ?
2017-04-06 2:39 GMT+05:00 David Sommerseth <
open...@sf.lists.topphemmelig.net>:
> On 05/04/17 23:13, debbie10t wrote:
> > I don't believe there is any need to specify "max" beca
Hi,
On 05/04/17 22:39, David Sommerseth wrote:
> On 05/04/17 23:13, debbie10t wrote:
>> I don't believe there is any need to specify "max" because that would be
>> --reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec
>
> I think you, probably without being aware of it, are agreeing
On 05/04/17 22:57, debbie10t wrote:
> Hi,
>
> On 05/04/17 22:39, David Sommerseth wrote:
>> On 05/04/17 23:13, debbie10t wrote:
>>> I don't believe there is any need to specify "max" because that would be
>>> --reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec
>>
>> I think you,
On 05/04/17 23:01, debbie10t wrote:
>
>
> On 05/04/17 22:57, debbie10t wrote:
>> Hi,
>>
>> On 05/04/17 22:39, David Sommerseth wrote:
>>> On 05/04/17 23:13, debbie10t wrote:
I don't believe there is any need to specify "max" because that
would be
--reneg-sec as is. Otherwise specif
On 05/04/17 23:43, Илья Шипицин wrote:
> hello!
>
> just curious how renegotiation is handled in "https" ?
> is it "an abbrevated ssl handshake" (RFC 2246) or ... ?
The HTTPS and OpenVPN protocol is not comparable in this regard at all.
AFAIR, OpenVPN does not make use of the TLS renegotiation po
One final clarification:
As a user, I would prefer to see an early 2fa re-connect than one in
the final few minutes, especially if I am already accustomed to a one
hour cut off. Such that, I do 45 mins of work and get cut off is more
annoying then doing 15 mins and get cut off.
Regards
---
On 05/04/17 23:57, debbie10t wrote:
> Hi,
>
> On 05/04/17 22:39, David Sommerseth wrote:
>> On 05/04/17 23:13, debbie10t wrote:
>>> I don't believe there is any need to specify "max" because that would be
>>> --reneg-sec as is. Otherwise specify a smaller or larger --reneg-sec
>>
>> I think you, p
On 06/04/17 00:30, debbie10t wrote:
>
> One final clarification:
>
> As a user, I would prefer to see an early 2fa re-connect than one in
> the final few minutes, especially if I am already accustomed to a one
> hour cut off. Such that, I do 45 mins of work and get cut off is more
> annoying then
2017-04-06 3:26 GMT+05:00 David Sommerseth <
open...@sf.lists.topphemmelig.net>:
> On 05/04/17 23:43, Илья Шипицин wrote:
> > hello!
> >
> > just curious how renegotiation is handled in "https" ?
> > is it "an abbrevated ssl handshake" (RFC 2246) or ... ?
>
> The HTTPS and OpenVPN protocol is not
28 matches
Mail list logo
