Steve at fivetrees wrote:
> "Tarmo Kuuse" <tarmo.kuuse@mail.ee> wrote in message 
> news:gulk4b$k6r$1@news.motzarella.org...
>> Dave Nadler wrote:
>>>> Idea of a central server was dismissed by client. There are neither
>>>> time, know-how nor resources to develop that.
>>> This is why we hired an inexpensive 3rd part provider, of which
>>> there are many...
>> I think the client weighs many design decisions by comparing their product 
>> with competitors' products. Since those do not sport such a fancy 
>> solution, it is not deemed necessary.
> 
> Understood - been there. Thanks for the update.
> 
>> A good demo would possibly change that. I love poking and toying, but the 
>> agreed work needs doing. Next time, maybe...
> 
> Yell if I can help with an OpenBSD gateway ;).

Thank you for the support :)

--
Kind regards,
Tarmo Kuuse

"Tarmo Kuuse" <tarmo.kuuse@mail.ee> wrote in message 
news:gulk4b$k6r$1@news.motzarella.org...
> Dave Nadler wrote:
>>> Idea of a central server was dismissed by client. There are neither
>>> time, know-how nor resources to develop that.
>>
>> This is why we hired an inexpensive 3rd part provider, of which
>> there are many...
>
> I think the client weighs many design decisions by comparing their product 
> with competitors' products. Since those do not sport such a fancy 
> solution, it is not deemed necessary.

Understood - been there. Thanks for the update.

> A good demo would possibly change that. I love poking and toying, but the 
> agreed work needs doing. Next time, maybe...

Yell if I can help with an OpenBSD gateway ;).

Steve
--
http://www.fivetrees.com 

David Brown wrote:
> Tarmo Kuuse wrote:
>> Idea of a central server was dismissed by client. There are neither 
>> time, know-how nor resources to develop that. I was considering a 
>> simple demo to change their minds, but the embedded side is no walk in 
>> the park. The TCP/IP stack in eCos is a KAME snapshot from 2002 which 
>> is supposed to support IPsec. However, documentation and API are 
>> effectively missing. I need to be a BSD TCP/IP and IPsec guru to 
>> create a minimal proof-of-concept.
>>
> I've lost track of the rest of your requirements, but whenever I see 
> "IPsec", I want to run the other way.  It causes all sorts of 
> complications, as do most other VPN or package encryption systems.  You 
> get trouble with incompatible software (each claiming to be "standard"), 
> routing, NAT, firewalling, MTU differences, etc.  OpenVPN uses SSL, 
> which is much easier, as it is only the contents of the packets that are 
> encrypted, not the addresses and headers.  Alternatively, use 
> application-level SSL (if you only need one or two protocols and ports, 
> and have control over the application software).  Again, it's far 
> easier, and it is secure against all but the most determined 
> professional-level attacks.

Noted.

--
Kind regards,
Tarmo Kuuse

Tarmo Kuuse wrote:
> 
> Idea of a central server was dismissed by client. There are neither 
> time, know-how nor resources to develop that. I was considering a simple 
> demo to change their minds, but the embedded side is no walk in the 
> park. The TCP/IP stack in eCos is a KAME snapshot from 2002 which is 
> supposed to support IPsec. However, documentation and API are 
> effectively missing. I need to be a BSD TCP/IP and IPsec guru to create 
> a minimal proof-of-concept.
> 


I've lost track of the rest of your requirements, but whenever I see 
"IPsec", I want to run the other way.  It causes all sorts of 
complications, as do most other VPN or package encryption systems.  You 
get trouble with incompatible software (each claiming to be "standard"), 
routing, NAT, firewalling, MTU differences, etc.  OpenVPN uses SSL, 
which is much easier, as it is only the contents of the packets that are 
encrypted, not the addresses and headers.  Alternatively, use 
application-level SSL (if you only need one or two protocols and ports, 
and have control over the application software).  Again, it's far 
easier, and it is secure against all but the most determined 
professional-level attacks.

Dave Nadler wrote:
>> Idea of a central server was dismissed by client. There are neither
>> time, know-how nor resources to develop that.
> 
> This is why we hired an inexpensive 3rd part provider, of which
> there are many...

I think the client weighs many design decisions by comparing their 
product with competitors' products. Since those do not sport such a 
fancy solution, it is not deemed necessary.

A good demo would possibly change that. I love poking and toying, but 
the agreed work needs doing. Next time, maybe...

>> ...but the embedded side is no walk in the
>> park. The TCP/IP stack in eCos is a KAME snapshot from 2002 which is
>> supposed to support IPsec. However, documentation and API are
>> effectively missing. I need to be a BSD TCP/IP and IPsec guru to create
>> a minimal proof-of-concept.
> 
> Yikes. This is why many of us are using Linux, all this stuff just
> works,
> and things like OpenVPN work great with no fuss.

Yes. This used to be a small, cheap, real-time subsystem and eCos was a 
perfect fit. It has grown out of it's shoes.

>> Not all is lost, though. The GSM data call can be used for PPP. The idea
>> is to have the user initiate dial-in from a modem or cell phone. Device
>> accepts the PPP connection and provides minimal service (only access to
>> the web interface).
> 
> Sorry, you lost me here.
> Which user initiates the GSM call ?
> Did you mean the device initiates the GSM call ?
> How do you get around the various NAT obstacles ?

User desiring remote access initiates the GSM call (or POTS call, if 
device has a dedicated data call number). Device accepts call, 
negotiates PPP link and serves web interface. There is no NAT, it's 
logically a direct link between user and device.

A PPP stack exists in eCos. It's API is designed to call the dial-in 
service, not accept incoming calls. However, PPP is symmetric and 
modifying the eCos implementation seems doable.

--
Kind regards,
Tarmo Kuuse

Thanks Tarmo for the update !

On May 15, 4:51=A0am, Tarmo Kuuse <tarmo.ku...@mail.ee> wrote:
> ....
> Idea of a central server was dismissed by client. There are neither
> time, know-how nor resources to develop that.

This is why we hired an inexpensive 3rd part provider, of which
there are many...

> ...but the embedded side is no walk in the
> park. The TCP/IP stack in eCos is a KAME snapshot from 2002 which is
> supposed to support IPsec. However, documentation and API are
> effectively missing. I need to be a BSD TCP/IP and IPsec guru to create
> a minimal proof-of-concept.

Yikes. This is why many of us are using Linux, all this stuff just
works,
and things like OpenVPN work great with no fuss.

> Not all is lost, though. The GSM data call can be used for PPP. The idea
> is to have the user initiate dial-in from a modem or cell phone. Device
> accepts the PPP connection and provides minimal service (only access to
> the web interface).

Sorry, you lost me here.
Which user initiates the GSM call ?
Did you mean the device initiates the GSM call ?
How do you get around the various NAT obstacles ?

Thanks again,
Best Regards, Dave

Hi!

> Let us know how you do it with eCos !

We gave up trying to provide ubiquitous remote access via Ethernet. User 
is responsible for setting up a VPN or SSH tunnel to remote site. Simply 
forwarding a public port to web interface is discouraged, but naturally 
we cannot stop users from doing that.

Idea of a central server was dismissed by client. There are neither 
time, know-how nor resources to develop that. I was considering a simple 
demo to change their minds, but the embedded side is no walk in the 
park. The TCP/IP stack in eCos is a KAME snapshot from 2002 which is 
supposed to support IPsec. However, documentation and API are 
effectively missing. I need to be a BSD TCP/IP and IPsec guru to create 
a minimal proof-of-concept.

Well, actually I started reading Stevens' "Volume 2", but it's mostly to 
educate myself and prepare for future challenges.

Not all is lost, though. The GSM data call can be used for PPP. The idea 
is to have the user initiate dial-in from a modem or cell phone. Device 
accepts the PPP connection and provides minimal service (only access to 
the web interface).

--
Kind regards,
Tarmo Kuuse

"chris" <cgruff@gmail.com> wrote in message 
news:7bf80549-e451-43d8-a583-8ef652c4a3b4@j8g2000yql.googlegroups.com...
>> On Mar 24, 6:39 pm, "Steve at fivetrees" <st...@NOSPAMTAfivetrees.com>
>
> However: you still need to ensure that the comms from the remote sites to
> the relay server(s) are secure. In our case we used dial-up - i.e. point 
> to
> point, and not public: the remote site dialled in, and was not externally
> accessible (it was a while ago). If you're using the Internet, then you
> probably need to block all ports *except* for one that you actively 
> manage -
> ideally by something strong like SSH. I'm sure you know not to be tempted 
> to
> try to be secure through obscurity, or to try to write your own...
>

Steve

I am interested in your closing statements.

 If one were to use, say, DES or AES, maintain secret 128 or 256 bit
keys at both ends, sport a reasonable random number generator and use
random challenge-response to logon and prepare 256-bit per-session
keys, then would you consider it to be dangerous to send messages back
and forth encrypted with the session keys?

Further assuming that the port used would be a high port and that the
traffic would be light and that the ISP wouldn't lock up the ports,
what would be the danger with protecting, say, somewhat personal
information, building access accounts, lightly-critical stuff like
that with this scenario?

I am very interested in your take on these questions, since having a
standalone internet appliance is so much more simple than the server-
centric solution that this thread is leaning toward.
<<

I'm not sure I'm qualified to answer. Probably like a lot of others, I have 
faith in certain platforms, in my case OpenBSD. If it's good enough for the 
OpenBSD developers, it's ok with me. They are *way* more paranoid than I am, 
and *way* better informed on the real threats and vectors. I've been running 
some very public systems since '99 with OpenBSD, and seen some concerted 
attacks, but never seen any succeed. I doubt I could have achieved that, on 
my own, especially with an embedded target running a TCP/IP stack I didn't 
write.

I would guess that if you know what you're doing (as you appear to), and 
have thought it through, and are using strong crypto from a source you 
trust, you'll be fine, whatever the architecture. My comments were based on 
the premise that it's rare to see such defences in embedded devices, which 
is unfortunate - hence my recommendations for either a strong gateway, or a 
strong centralised server and proprietary (encrypted) comms to/from the 
remote devices. Certainly it's madness to expose e.g. an unprotected 
embedded HTTP/CGI server directly to the Internet without some form of 
packet filtering and a good understanding of the nature of the threats.

Hope this helps. Not sure it will ;).

Steve
--
http://www.fivetrees.com 

On Mar 24, 6:39=A0pm, "Steve at fivetrees" <st...@NOSPAMTAfivetrees.com>
wrote:
> "Tarmo Kuuse" <tarmo.ku...@mail.ee> wrote in message
>
> news:gqb4ed$18l$1@news.motzarella.org...
>
>
>
>
>
> > zwsdot...@gmail.com wrote:
> >> There are various methods employed, though not so popular in this day
> >> and age. One method is to use a proprietary and encrypted protocol
> >> tunneled over port 80. Your embedded device is visible to the world,
> >> but all it serves up is a Java application that runs in the client-
> >> side browser and communicates using an encrypted data stream. That is
> >> fairly transparent to end-users insofar as the "software installation"
> >> happens as soon as they navigate to the device's page.
>
> > An initial proposal was to implement the entire user interface as a Jav=
a
> > applet and use a simple back-end protocol to move data. Traditional web
> > interface seems to be a more robust solution so Java was dropped.
>
> > Anyway, it occurs to me that device could open a connection to Internet
> > instead of waiting for an incoming one.
>
> > Device opens a TCP connection to a public relay server. They authentica=
te
> > each other and the connection is kept alive indefinitely.
>
> > The user who desires access connects to relay server with a browser and
> > logs in. The server then relays all HTTP requests to device (via existi=
ng
> > TCP connection) and passes the HTTP responses back to client.
>
> > Pros: no incoming connections, NAT and dynamic public IP become
> > transparent, no web security problems
>
> > Cons: need relay server, need tunneling protocol.
>
> > Hmm, gotta think some more.
>
> Further to my earlier post re manful gateways: again, I've run into exact=
ly
> this (no extra cost/infrastructure on site allowed), and what you describ=
ed
> is how we fixed it. A relay (management) server actually opens up a lot o=
f
> possibilities: look on it as added, centralised value - you can do far mo=
re
> there than you can at each remote site, including logging, account
> management, upgrades, etc etc etc.
>
> However: you still need to ensure that the comms from the remote sites to
> the relay server(s) are secure. In our case we used dial-up - i.e. point =
to
> point, and not public: the remote site dialled in, and was not externally
> accessible (it was a while ago). If you're using the Internet, then you
> probably need to block all ports *except* for one that you actively manag=
e -
> ideally by something strong like SSH. I'm sure you know not to be tempted=
 to
> try to be secure through obscurity, or to try to write your own...
>
> Steve
> --http://www.fivetrees.com- Hide quoted text -
>
> - Show quoted text -

Steve

I am interested in your closing statements.

 If one were to use, say, DES or AES, maintain secret 128 or 256 bit
keys at both ends, sport a reasonable random number generator and use
random challenge-response to logon and prepare 256-bit per-session
keys, then would you consider it to be dangerous to send messages back
and forth encrypted with the session keys?

Further assuming that the port used would be a high port and that the
traffic would be light and that the ISP wouldn't lock up the ports,
what would be the danger with protecting, say, somewhat personal
information, building access accounts, lightly-critical stuff like
that with this scenario?

I am very interested in your take on these questions, since having a
standalone internet appliance is so much more simple than the server-
centric solution that this thread is leaning toward.

Thanks!

Chris Ruff

On Mar 25, 9:01=A0am, Tarmo Kuuse <tarmo.ku...@mail.ee> wrote:
> DRN wrote:
> > I just finished solving *almost* this problem a couple months back.
> > Almost because our box:
> > - runs Linux, and
> > - has GSM (receives text messages and runs GPRS)
>
> > Service is initiated by sending a text message, whereupon the box
> > starts openvpn... Works great ! openvpn's well-know port is not
> > blocked by the telecom providers NAT boxes =A0(this system is using
> > GPRS for the connection, no hardwired access available).
>
> Let me see if I understood correctly. Your box contains a VPN client and
> connects to an OpenVPN server in the Internet?
>
> That sounds outrageously nice. A fleet of remote devices, full-blown
> local networking, flexible segmenting and architecture, single point of
> control.
>
> > Let us know how you do it with eCos !
>
> I hope it will not end up being too embarrassing to publicly post it ;)
>
> --
> Kind regards,
> Tarmo Kuuse

Right, OpenVPN server in the Internet serves as bridge (since
technician typically also connects from behind a NAT box).

Looking forward to hearing of your solution,
Best Regards, Dave