Re: [Fwknop-discuss] Fwd: Bad timestamp with fwknop-client 1.8.3

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Thanks to all for the discussion, glad to hear I wasn't crazy when I saw the
Windows client not working.  I believe Sean mentioned a quick release of a
patched client to test, I love to see it and it should be small enough to
receive by email.

My two cents (and apologies for overtyping), but isn't UnixTime the number
of seconds since Jan.1, 1970 GMT, and therefore shouldn't be adjusted for
local timezones unless required by a presentation (or other) layer?
Therefore, the same integer representation of UnixTime should always be
understood by all parties, because by definition it is not locally adjusted
from GMT?  All apologies if I'm mistaken by this, and I freely didn't look
into the Windows API time calls, but my gut feeling is that if the client
code is adjusting for timezone it is the client that should be modified
rather than Michael's gracious request to modify the server.  It's curious
that the developer and others need this fix on the UI client, I wish I could
help.

Or I'm completely wrong, not claiming authority, nor being accusatory :)
I'd love to get a Cygwin version working as well, my attempt kept getting a
Rijndael decrypt failure from the packet received, but if I get a chance I
might try and debug further.  Eternal thanks to all parties on all their
hard work!

Grant

> -----Original Message-----
> From: Michael Rash [mailto:mb...@ci...]
> Sent: May 20, 2008 9:09 PM
> To: Sean Greven
> Cc: Sebastien J.; Michael Rash; fwk...@li...;
> Grant Ferley
> Subject: Re: [Fwknop-discuss] Fwd: Bad timestamp with fwknop-client
> 1.8.3
> 
> On May 20, 2008, Sean Greven wrote:
> 
> > Hi there
> 
> Hi Sean -
> 
> > The code which deals with the timestamp, is as follows
> >
> > function Timestamp ( ): string;
> > var
> >   tstamp: integer;
> >   secondsoffset: integer;
> >   timezoneinfo: TTimezoneinformation;
> > begin
> >   GetTimezoneInformation ( timezoneinfo);
> >   secondsoffset := timezoneinfo.Bias * 60;
> >   tstamp := DateTimeToUnix ( Now) + secondsoffset;
> >   Result := IntToStr ( tstamp);
> > end;
> >
> > The GetTimezoneInformation is basically a windows API call, which
> > seems to assume GMT.
> >
> > I just need to figure out how to determine programatically if the
> > machine uses GMT or UTC, or would a simple patch suffice, to add a
> > checkbox on the UI, which permits the user to select UTC
> calculations,
> > since the unixtime calculation is DateTimeToUnix ( Now) +
> > secondsoffset , for GMT but will just be DateTimeToUnix ( Now).  I
> can
> > easily fix this, but it will break a whole bunch of stuff for people
> > like me who need the offset.
> >
> > Sorry Guys I personally never put much stock in the windows API, and
> > the fact that there is no native function that correctly deals with
> > epochtime under windows, I need some advice here.
> 
> I think a good strategy might be for me to update the fwknopd daemon to
> allow the user to configure it to accept timestamps in either GMT or
> UTC
> (or both).  This would provide maximum flexibility, and allow your UI
> to
> continue to use the offset.  Sound ok?
> 
> Thanks,
> 
> --
> Michael Rash
> http://www.cipherdyne.org/
> Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F
> 
> >
> > Regards Sean.
> >
> > In the meantime, I can always send a patched version to whomever
> wants one
> >
> >
> > On Tue, May 20, 2008 at 9:55 AM, Sebastien J.
> <in...@se...> wrote:
> > > Hi Grant,
> > >
> > > Indeed, I've been discussing this issue with Mike this week.
> Something
> > > in the GUI is definitely miscalculating the time. Hopefully Sean,
> who
> > > coded the GUI, can possibly give us an update to the GUI and bring
> it up
> > > to 1.9.3. Ideally someone would be up to the challenge of starting
> a
> > > Java GUI, that could then be used on any OS. I've been looking for
> a
> > > possible way of wrapping the perl script inside a Java wrapper, as
> this
> > > would make updating the GUI a lot easier. But I'm not sure if
> that's doable.
> > >
> > > If you need to use fwknop from a windows machine, I recommend
> either
> > > trying to run the perl script under Cygwin (which I have not
> managed to
> > > do so far due Cygwin FAIL) - the other option, which I don't
> recommend
> > > in the long-term, as it technically may reduce the security of SPA,
> is
> > > to set the ENABLE_SPA_PACKET_AGING value in the fwknop.conf file to
> 'N'.
> > > This will cause fwknopd to ignore the timestamp. Although fwknopd
> still
> > > checks the authorization packet hash, it will not reject packets
> that
> > > might have been sent but never received (eg. block and replay
> attacks).
> > >
> > > Sincerely,
> > > Sebastien
> > > --
> > > Securethoughts.net
> > > Single Packet Authorization Forums:
> > > http://www.securethoughts.net/forum/viewforum.php?f=6
> > >
> > >>
> > >> ---------- Forwarded message ----------
> > >> From: *Grant Ferley* <gfc...@mt...
> <mailto:gfc...@mt...>>
> > >> Date: Mon, May 19, 2008 at 10:57 PM
> > >> Subject: [Fwknop-discuss] Bad timestamp with fwknop-client 1.8.3
> > >> To: fwk...@li...
> > >> <mailto:fwk...@li...>
> > >>
> > >>
> > >> Hey to the list:
> > >>
> > >>
> > >>
> > >> Tried using the Windows fwknop UI v1.8.3 on my WinXP SP3, no luck.
> > >> The server side was reporting a bad timestamp, so I debugged and
> found
> > >> that the timestamp on the incoming packet was ahead by around
> 3000+
> > >> seconds.  Being in Central time, I'm figuring that the Windows UI
> > >> might be improperly adjusting the UTC timestamp for GMT offset
> when it
> > >> shouldn't.  I used a previous fwknop UI without issue (not sure
> which
> > >> version, from December?), and Linux clients work fine as always.
> My
> > >> time is synched to the same source on both client and server.
> > >>
> > >>
> > >>
> > >> I thought about hacking the client code to see for sure, but it's
> > >> Pascal and the last Pascal compilation I did was on an Apple IIe.
> I'd
> > >> love to hear if anyone else can confirm this issue.
> > >>
> > >>
> > >>
> > >> Thanks
> > >>
> > >>
> > >>
> > >> Grant
> > >>
> > >>
> > >
> > >
> > > -------------------------------------------------------------------
> ------
> > > This SF.net email is sponsored by: Microsoft
> > > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > _______________________________________________
> > > Fwknop-discuss mailing list
> > > Fwk...@li...
> > > https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
> > >
> >
> > ---------------------------------------------------------------------
> ----
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Fwknop-discuss mailing list
> > Fwk...@li...
> > https://lists.sourceforge.net/lists/listinfo/fwknop-discuss