>If these things don't have access to the Internet, what security concerns
are
>you trying to address by using encryption at all?

I'm going to answer these in reverse order, I think that will make more
sense.

>Maybe you could explain where the IoT devices are and where Apache is, in
>networking terms, so we can understand what communications you are trying
to
>secure, and against what threats.

The devices are very simple embedded controllers, and they're monitoring
environmental factors, the exact things they monitor depends on how they're
configured.
Here's one example, the unit has a temperature probe sensor for monitoring
refrigerator temperatures. It sends temperature status readings every few
minutes over wifi to Apache.  Apache then logs the data into a database.
The unit also can instantly send a message to Apache if the device being
monitored gets outside of a predetermined range.
The unit also regularly requests configuration updates, which can change
various internal parameters (how often to report, what is considered out of
range, etc.).  This can also do an over-the-air update to download new
firmware.

Apache is installed on a dedicated computer with a private wifi network
that houses the control scripts, update files, and database.  This machine
is also not internet connected.  The machine can be queried to create
reports on the data, and can reach out to a third machine (via wired lan)
to send alerts if something goes out of range. It currently runs a version
of Debian.

The security concerns are two fold, one technical, one political.
Here's an example:
Say the unit is monitoring a refrigerator temperature in a pharmacy in a
hospital.  If the temperature gets out of range, the drugs inside need to
be discarded for patient safety.  The unit will alert before that threshold
is reached, but the overall data is used for manufacturer compliance and
legal protection.  Being able to produce reports and graphs of the
refrigerator temperature eliminates a good bit of patient and legal risk.

The technical issue is fairly straightforward. Using PSK, only devices that
have the PSK can talk to Apache, giving a degree of validation that only
verified devices can send data.  This is for data integrity purposes.
Others cannot connect. In a large (physical size) organization, they can be
configured to connect over the location's internal WiFi so WiFi encryption
alone is not sufficient.

The political issue is (imho) kind of pointless but very real.  Many
organizations have little checklists that will eliminate you from competing
for business.  Very often there will be a requirement like "All
communication is encrypted using a minimum of TLS 1.2 or higher". If you
can't pass that checkbox, you are disqualified.

So the question is:
Can I configure Apache to use PSK (preferably TLS1.3 version of PSK) by
sharing a key between the server and the client?

I hope that makes it more clear.

-Garry





On Sun, May 30, 2021 at 3:57 AM Antony Stone <
antony.st...@apache.open.source.it> wrote:

> On Sunday 30 May 2021 at 08:43:59, Garry Adkins wrote:
>
> > Hi,
> >
> > I'm new to the maling list, and was wondering if anyone used pre-shared
> > keys with Apache for encrypted connections?
>
> I don't know about PSK with Apache, but...
>
> > I'm working with some processor constrained IOT devices, and doing a full
> > TLS 1.3 setup is quite heavy.  These devices don't have access to the
> > internet, so updating certs becomes a problem too.
>
> If these things don't have access to the Internet, what security concerns
> are
> you trying to address by using encryption at all?
>
> Maybe you could explain where the IoT devices are and where Apache is, in
> networking terms, so we can understand what communications you are trying
> to
> secure, and against what threats.
>
>
> Antony.
>
> --
> "If I've told you once, I've told you a million times - stop exaggerating!"
>
>                                                    Please reply to the
> list;
>                                                          please *don't* CC
> me.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>

-- 
Garry Adkins
****************************************************
https://www.linkedin.com/in/garryadkins/
garryadk...@gmail.com
251-487-1803 (c)

Reply via email to