The Market Ticker
Commentary on The Capital Markets- Category [Technology]
Logging in or registering will improve your experience here
Main Navigation
MUST-READ Selection(s):
There Can Be NO Compromise On Data

Display list of topics

Sarah's Resources You Should See
Sarah's Blog Buy Sarah's Pictures
Full-Text Search & Archives

Legal Disclaimer

The content on this site is provided without any warranty, express or implied. All opinions expressed on this site are those of the author and may contain errors or omissions.

NO MATERIAL HERE CONSTITUTES "INVESTMENT ADVICE" NOR IS IT A RECOMMENDATION TO BUY OR SELL ANY FINANCIAL INSTRUMENT, INCLUDING BUT NOT LIMITED TO STOCKS, OPTIONS, BONDS OR FUTURES.

The author may have a position in any company or security mentioned herein. Actions you undertake as a consequence of any analysis, opinion or advertisement on this site are your sole responsibility.

Market charts, when present, used with permission of TD Ameritrade/ThinkOrSwim Inc. Neither TD Ameritrade or ThinkOrSwim have reviewed, approved or disapproved any content herein.

The Market Ticker content may be sent unmodified to lawmakers via print or electronic means or excerpted online for non-commercial purposes provided full attribution is given and the original article source is linked to. Please contact Karl Denninger for reprint permission in other media, to republish full articles, or for any commercial use (which includes any site where advertising is displayed.)

Submissions or tips on matters of economic or political interest may be sent "over the transom" to The Editor at any time. To be considered for publication your submission must include full and correct contact information and be related to an economic or political matter of the day. All submissions become the property of The Market Ticker.

Considering sending spam? Read this first.

2018-05-23 12:59 by Karl Denninger
in Technology , 106 references
[Comments enabled]  

Might want to read this Ticker again....

As of now this problem is, generally-speaking, solved.

Your IP camera does not need to be visible from the outside.  At all.

You also never need to store its password anywhere outside -- not even on your phone.

The HomeDaemon app also never stores the password to either the camera or the HomeDaemon controller; it authenticates using a key that it maintains while running (and can be set to run in the background), and the controller, on demand, negotiates with the camera, gets the unencrypted stream, encrypts it using SSL and a private-CA secured certificate (that is essentially unbreakable), and displays it.

There remain some issues with bandwidth consumption and for that reason I'm not currently using the highest resolution stream capacity available (especially on the 2k+ cameras!) but I have managed to get the latency down to roughly 1 second, which isn't bad at all.

All this on a Pi2, which has about a quarter of the power of the newer Pi3 series.

Encapsulating with the higher resolution and lower bandwidth consumption options is being worked on, as is the ability to move the camera both to presets and arbitrarily, along with setting the camera's presets.  Those latter capabilities are, since I have the camera interface worked out, simply a matter of adding the buttons to the screen.

Are you in the business of providing home automation solutions or selling houses with so-called "smart" features?  This is the one you want.

You can not only control and monitor everything in your house with real time notifications, zero cloud storage or use (therefore nothing to steal!) but the system also integrates fully with any of the Amcrest camera family.

Look to the right for contact info; it's available right here, right now.  Buy it all and make a fortune.

View this entry with comments (opens new window)
 

2018-05-17 10:08 by Karl Denninger
in Technology , 161 references
[Comments enabled]  

You're not going to like this.

Got a "Ring" doorbell?  Or, for that matter, any of those other nice IP cameras?  Doesn't matter who makes them, by the way.

Most security-conscious people are aware that there's a huge problem with allowing any sort of "cloud" storage option to be turned on.  Many people don't care, but you damn well should.

But here's the other problem that comes with these things: The video stream itself is totally insecure and your credentials are not much safer.

I'm unfortunately forced to recommend at this point that all such devices be immediately shut down in terms of off-premise access to the video.  Period.  Full-stop.  Right now.

The reason is a bit complex, so hopefully you'll read the whole thing to understand it.

Here's a typical start-up transaction for real-time video streaming to one of these cameras:

13:15:16.697677 IP (tos 0x0, ttl 63, id 20712, offset 0, flags [DF], proto TCP (6), length 163)
D2.Denninger.Net.50501 > 192.168.4.211.rtsp: Flags [P.], cksum 0xc419 (correct), seq 1:112, ack 1, win 343, options [nop,nop,TS val 7363585 ecr 37265593], length 111: RTSP, length: 111
OPTIONS rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0 RTSP/1.0
CSeq: 1
User-Agent: Live555

I want to look at the camera in real-time, main channel and normal "substream" (different resolutions, etc) using RTSP (streaming video)


192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [P.], cksum 0x2c43 (correct), seq 1:143, ack 112, win 905, options [nop,nop,TS val 37265595 ecr 7363585],length 142: RTSP, length: 142
RTSP/1.0 401 Unauthorized
CSeq: 1
WWW-Authenticate: Digest realm="Login to AMC000PD39KR3820JT", nonce="da8
684cec2ea70ff015538fb006139e3"

Heh jackass, you didn't give me any sort of credentials -- go away or tell me who you are with a password.

13:15:16.724851 IP (tos 0x0, ttl 63, id 20714, offset 0, flags [DF], proto TCP (6), length 394)
D2.Denninger.Net.50501 > 192.168.4.211.rtsp: Flags [P.], cksum 0xb072 (correct), seq 112:454, ack 143, win 347, options [nop,nop,TS val 7363588 ecr 37265595], length 342: RTSP, length: 342
OPTIONS rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0 RTSP/1.0
CSeq: 2
User-Agent: Live555
Authorization: Digest username="karl", realm="Login to AMC000PD39KR3820JT", nonce="da8684cec2ea70ff015538fb006139e3", uri="rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0", response="20dc9cda80205b5d2d8f2ae9c335dc27"

Ok, I'm Karl and here's a password for that previously-requested video stream.  Can I have it now?

Note that there is no actual password.  There's a "nonce" and a "response", both of which are not clear text.  The reason is that the camera (thankfully) demanded "digest" authentication.  Note that some earlier versions of camera software allowed "basic", which transmitted credentials -- including the password itself -- in plain text.

Amcrest shut that off about a year ago which is a good thing.  When they did they broke a lot of third-party software that, believe it or not, actually used and relied on plain-text passwords being sent over the wire.  That's so stupid it belies basic logic, but there was a lot of third-party code out there that did.  The fact that Amcrest forcibly disabled this by removing the option from their firmware is one of the reasons I've sort of liked their cameras -- they at least try.

The problem, however, will become clear momentarily....  let's continue.

13:15:16.741703 IP (tos 0x0, ttl 64, id 4151, offset 0, flags [DF], proto TCP (6), length 210)
192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [P.], cksum 0x9460 (correct), seq 143:301, ack 454, win 972, options [nop,nop,TS val 37265597 ecr 7363588], length 158: RTSP, length: 158
RTSP/1.0 200 OK
CSeq: 2
Server: Rtsp Server/3.0
Public: OPTIONS, DESCRIBE, ANNOUNCE, SETUP, PLAY, RECORD, PAUSE, TEARDOWN, SET_PARAMETER, GET_PARAMETER

I'm the camera, I like you and your password is good.  Here is what I know how to do with the RTSP protocol.  Please tell me how to proceed.

D2.Denninger.Net.50501 > 192.168.4.211.rtsp: Flags [P.], cksum 0xa4a0 (correct), seq 454:822, ack 301, win 351, options [nop,nop,TS val 7363590 ecr 37265597], length 368: RTSP, length: 368
DESCRIBE rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0 RTSP/1.0
Accept: application/sdp
CSeq: 3
User-Agent: Live555
Authorization: Digest username="karl", realm="Login to AMC000PD39KR3820JT", nonce="da8684cec2ea70ff015538fb006139e3", uri="rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0", response="55f38faa28da02835fdfd2de248f1632"

Ok, please tell me what the stream that is identified as channel 1, subchannel 0 looks like.  Oh, and here's authentication credentials again (note the "response" is different, because the hash includes the command, in this case "DESCRIBE" (with parameters) although the nonce has not been re-generated (this is part of problem #3 I'll get to later)

 

13:15:16.759068 IP (tos 0x0, ttl 64, id 4153, offset 0, flags [DF], proto TCP (6), length 773)
192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [P.], cksum 0xbee2 (correct), seq 301:1022, ack 822, win 1039, options [nop,nop,TS val 37265599 ecr 7363590], length 721: RTSP, length: 721
RTSP/1.0 200 OK
CSeq: 3
x-Accept-Dynamic-Rate: 1
Content-Base: rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0/
Cache-Control: must-revalidate
Content-Length: 506
Content-Type: application/sdp

v=0
o=- 2252311096 2252311096 IN IP4 0.0.0.0
s=Media Server
c=IN IP4 0.0.0.0
t=0 0
a=control:*
a=packetization-supported:DH
a=rtppayload-supported:DH
a=range:npt=now-
m=video 0 RTP/AVP 96
a=control:trackID=0
a=framerate:13.000000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=640029;sprop-parameter-s
ets=Z2QAKaw0yAeAIn5cBbgICAoAAAfQAADLIdDACpIACpFXeXGhgBUkABUirvLhQAA=,aO48MAA=
a=recvonly
m=audio 0 RTP/AVP 8
a=control:trackID=1
a=rtpmap:8 PCMA/16000
a=recvonly

Here's a bunch of information for you describing the media you requested.  The frame rate, the format of it, the audio that's included and its bitrate, etc -- all of which you'll need in order to successfully decode and display the video.  Oh, and your password is still good because I said "ok".

D2.Denninger.Net.50501 > 192.168.4.211.rtsp: Flags [P.], cksum 0xbc55 (correct), seq 822:1249, ack 1022, win 357, options [nop,nop,TS val 7363592 ecr 37265599], length 427: RTSP, length: 427
SETUP rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0/trackID=0 RTSP/1.0
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
x-Dynamic-Rate: 0
CSeq: 4
User-Agent: Live555
Authorization: Digest username="karl", realm="Login to AMC000PD39KR3820JT", nonce="da8684cec2ea70ff015538fb006139e3", uri="rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0/trackID=0", response="a069805debe9e14f99804d37242eac50"

Thank you.  Please set up to play the stream in question (I've decided I can understand it), and by the way, here's another hash (with my password of course) just so you know it's really me.

13:15:16.776718 IP (tos 0x0, ttl 64, id 4154, offset 0, flags [DF], proto TCP (6), length 195)
192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [P.], cksum 0xf8ba (correct), seq 1022:1165, ack 1249, win 1106, options [nop,nop,TS val 37265601 ecr 7363592], length 143: RTSP, length: 143
RTSP/1.0 200 OK
CSeq: 4
Session: 372956013002;timeout=60
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=6D23767F
x-Dynamic-Rate: 1

Ok, you're good.  We're ready to go whenever you are, but the session I'm setting up for you is only valid for the next 60 seconds.  I'm going to send it over TCP, here's a session ID so you know it's the right one when it starts and oh, your password is still ok.

13:15:16.780403 IP (tos 0x0, ttl 63, id 20717, offset 0, flags [DF], proto TCP (6), length 435)
D2.Denninger.Net.50501 > 192.168.4.211.rtsp: Flags [P.], cksum 0xb842 (correct), seq 1249:1632, ack 1165, win 362, options [nop,nop,TS val 7363594 ecr 37265601], length 383: RTSP, length: 383
PLAY rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0/ RTSP/
1.0
Range: npt=0.000-
CSeq: 5
User-Agent: Live555
Session: 372956013002
Authorization: Digest username="karl", realm="Login to AMC000PD39KR3820JT", nonce="da8684cec2ea70ff015538fb006139e3", uri="rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0/", response="b215d803b422a92152c11d1abcf94387"

All good.  Start the stream please, play from time 0.000 on the session ID you previously set up for me.  Oh, and here's my credentials again.


13:15:16.816148 IP (tos 0x0, ttl 64, id 4156, offset 0, flags [DF], proto TCP (6), length 176)
192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [P.], cksum 0x97a8 (correct), seq 1165:1289, ack 1632, win 1173, options [nop,nop,TS val 37265605 ecr 7363594], length 124: RTSP, length: 124
RTSP/1.0 200 OK
CSeq: 5
Session: 372956013002
Range: npt=0.000000-
RTP-Info: url=trackID=0;seq=32390;rtptime=2924735

Here it comes!

192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [P.], cksum 0x4d5c (correct), seq 1289:1341, ack 1632, win 1173, options [nop,nop,TS val 37265609 ecr 7363601], length 52: RTSP
13:15:16.871343 IP (tos 0x0, ttl 63, id 20719, offset 0, flags [DF], proto TCP (6), length 52)
D2.Denninger.Net.50501 > 192.168.4.211.rtsp: Flags [.], cksum 0x9535 (correct), ack 1341, win 362, options [nop,nop,TS val 7363602 ecr 37265609], length 0
13:15:16.962682 IP (tos 0x0, ttl 64, id 4158, offset 0, flags [DF], proto TCP (6), length 1500)
192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [.], cksum 0x5aa7 (correct), seq 1341:2789, ack 1632, win 1173, options [nop,nop,TS val 37265619 ecr 7363602], length 1448: RTSP
13:15:16.962846 IP (tos 0x0, ttl 64, id 4159, offset 0, flags [DF], proto TCP (6), length 1500)
192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [.], cksum 0xdfe3 (correct), seq 2789:4237, ack 1632, win 1173, options [nop,nop,TS val 37265619 ecr 7363602], length 1448: RTSP

And there it is.... there's a lot more of course but these are the start of the packets containing the actual video.

Now here are the problems, in order:

1. RTSP is unencrypted. This means that the actual video is flowing over the network with absolutely zero encryption of any sort, and anyone in the middle can pick it off.  Watching it on a WiFi network that is unsecured in some coffee shop?  Everyone within 200' of you can see your video.  Is that your cute kid on the "baby monitor" or your empty house?  That wouldn't be a problem, right?

2. Every three-letter spook and criminal malefactor who can access any part of the infrastructure between you and the camera can also trivially decode and display that video in real-time.  Yes, I said anyone.  It requires exactly zero coding or effort to display an RTSP stream you capture; simply feed it to any media player that understands the format and voila -- there you are.  This means that any time you have an actual video stream running anyone who is sufficiently motivated can watch it too at the same time you do or grab the stream, save it to their device and watch it whenever they'd like.  There is not a single online store or financial institution that finds this sort of crap acceptable which is why they all have those little padlocks (https) on their web pages.

3. MD5 is not secure.  That's what "digest" uses to hash those passwords.  It's better than sending them in plain text over the Internet, but not that much better.  While someone who gets a single session would probably have trouble breaking your password someone who manages to get a bunch of these negotiations over time absolutely can do so.  I will note that MD5 was deprecated a long time ago as a sufficiently good digest for hashing passwords in general and it's also not considered acceptable as a hashing algorithm in SSL either, for the same reason -- it's not very hard to break.  If your camera is connected to any sort of "central" or "cloud" service those transactions are all going to one destination and thus you must assume your password has been stolen.  Once stolen, of course, said bad actor can now break into your camera at any time in the future, not just when you're watching it.  Again, I repeat: If you allow your "IP camera" to connect to or if you use any sort of "cloud" storage, control or similar facility you must assume that the login credentials have been compromised.

I've made a "command decision" when it comes to HomeDaemon's app -- it's not going to support doing that as it stands although literally every single damn app out there right now does.  No way am I doing that with my code as it's a blatant and severe security problem.

Instead what I support now is SSL-encrypted transport of captured stills, which is easy because I already use SSL-encrypted transport to talk to the server, the server has the ability to ask the camera for stills already, both are on the same local LAN which is encrypted with AES (and thus reasonably secure) and HomeDaemon-MCP (the server code) already knows how to enforce permissions for sessions so you not only need to authenticate but some users can have access to the camera images and others not, as you wish.  That is secure off-premise right here, right now because (1) the camera is not directly sending the picture, HomeDaemon-MCP is, (2) it demanded and got an SSL connection to the client on the phone and (3) the transport is thus safe from interception or even knowledge that you made the request.

So if you click a camera icon on the HomeDaemon-MCP app what you'll get is the most-recent still the camera has captured, usually configured on the base code to be snapped whenever the camera "sees" movement -- instead of a real-time video stream.

What I'm investigating supporting (if I can figure out how to feed Android's media decoder and display tools bidirectionally with arbitrary streams of data) is a secure, SSL-encrypted tunnel for that video generated by HomeDaemon-MCP and the app, removing the risk for video displayed through the app.  You can then absolutely block all outside access to the cameras, period, at your firewall without losing functionality.  The power consumption on the phone doing this might make you grimace due to the data rate involved but if I can figure it out the transport will be secure.  My first blush look at this is that it's not something either the stock mediaplayer or Exoplayer were designed to handle; the former is part of the framework and not designed to be modified at all, but the latter is an open-source project.  In any event it doesn't look like a "quick" thing to support, if it's even reasonable to do at all given the current state of the Android codebase.  It might not be.

I suspect the reason there is no "RTSPS" is that these cameras simply don't have the CPU horsepower to run SSL encryption for a video stream at the data rates required without puking, and fixing that would massively increase the cost of the cameras.  That makes sense but it means that every single IP camera out there right now is trivially intercepted by anyone sufficiently motivated to do so when in actual use to view video, and any connected to a cloud account gives anyone sufficiently interested a nasty and unencrypted "choke point" through which to collect enough digest information to break your password.

I repeat: As it stands right now Internet-accessible streaming cams at minimum expose the actual video in real time to anyone who cares to intercept it without any sort of real effort and any connected to a cloud service of any sort almost-certainly wind up divulging enough information to make compromise of your password and thus permanent access to same quite easy.

Psst.... if you're in the "home control and monitoring" business, or anything associated with it.... yes, the entire codebase is for sale as I've pointed out before.  Who wants to have the competitive advantage of their systems not being trivially watched by the neighborhood crook say much less organized rings of same?  Email me.....

View this entry with comments (opens new window)
 

2018-05-15 07:00 by Karl Denninger
in Technology , 151 references
[Comments enabled]  

I tire of this crap.

May 12 11:43:51 HD-MCP HD-MCP[30449]: SSL ACCEPT Error [http request] on [::ffff:31.184.193.154]
May 12 11:43:52 HD-MCP last message repeated 130 times

That would be in Russia.

Then there's this one:

May 12 11:42:15 HD-MCP HD-MCP[30449]: SSL ACCEPT Error [http request] on [::ffff:189.47.119.165]
May 12 11:42:15 HD-MCP last message repeated 169 times

That's Brazil.

May 11 22:01:36 HD-MCP HD-MCP[30449]: SSL ACCEPT Error [http request] on [::ffff:189.129.177.1]
May 11 22:01:36 HD-MCP last message repeated 220 times

And that's from our great friends the NAFTA folks -- Mexico.

Where's my "nuke the source of that crap until it glows" button?

No, they're not an "innocent" series of accidents.  Not with well north of 100 attempts each within a few seconds.  Nor are they isolated -- that's just a small sample.

Oh, if you want to know why you need something like HomeDaemon instead of software written in a "high level" (high-overhead) language, this sort of garbage would be why -- it laughs such attempts off, even on $35 hardware.

With a "bit" more overhead.... it won't be as non-disruptive of an experience for you.

View this entry with comments (opens new window)
 

2018-04-17 11:43 by Karl Denninger
in Technology , 168 references
[Comments enabled]  

My HomeDaemon-MCP controller has always "attracted" a certain number of "probes", nearly all of which result in a log entry that looks like this:

[10:18] SSL ACCEPT Error [http request] on [::ffff:103.254.156.xxx]

These are connections that are made to the controller and the SSL negotiation fails because the other end doesn't respond at all to it.  That is, it doesn't get back a bad negotiation or attempt to play games with the SSL protocol, it simply gets nothing, a bare HTTP request, or something similar (e.g. someone thinks it might be a Telnet server, for example.)

HomeDaemon-MCP contains its own web server; it does not rely on something like ngnix or Apache.  The reason for this is that the required set of capabilities is well-defined and it's much more-secure to write code that does what you need, along with interdicting attempts to be "bad" (and reporting them) than it is to rely on someone else's brain-fart which, due to the complexity of what it must handle, is inherently much larger and thus has a far larger attack surface.

In the last 48 hours or so the number of "probes" have exploded as apparently Russia and a handful of other locations (the Czech republic, for one) have decided to "ratchet up" attempted assaults on various "Internet of Things" devices.  I'm now seeing these reported not one or two at a time but by the hundreds, back-to-back.  There has also been a marked increase in the number of what appear to be "white hat" surveillance attempts on said devices, including mine, looking for potential vulnerabilities.  The fact that the "bad guys" know I'm here and how to find me isn't surprising in the main.  That the white hat guys are also hammering me is, because the presumption has to be that their primary means of finding me is an exhaustive port-scan on IP address ranges.

Why the "bad guys"?  Because I've been at this sort of stuff long enough, and am well-enough known from my days of running an ISP, that my presumption is that they know who I am and are at least passingly interested in trying to steal things -- like my software.  Maybe I'm wrong and they're just randomly looking too, but I wouldn't take that bet.

This appears to be related, according to the "white hat" folks, to this CERT alert -- and it's a NASTY one.

But HomeDaemon-MCP is laughing all of these attempted assaults off -- both the "white hat" probes and the far more-malicious "black hat" sort.

It's not at all impossible to write IOT code -- HomeDaemon-MCP is one such instance -- that is reasonably secure.

However, it's very hard to cheat and use libraries to do huge amounts of security-sensitive parts of the processing, including the web service part, and actually maintain security because the code isn't yours, even if you attempt to audit it you didn't write it and thus don't have a full understanding of it, and if there is a problem found you're reliant on someone else to fix it.  It gets even worse if you're writing in something like PHP.

That's why HomeDaemon-MCP doesn't do any of that and I took the time and effort to write it on the metal using "C", with the only outside dependency being the OpenSSL libraries.

A reasonably-full description of HomeDaemon-MCP can be found here; it speaks not only Z-Wave with an inexpensive USB "stick" but also can manage independent and fully-internal analog input monitoring using an extremely inexpensive ADC "bolt on" but also GPIO (digital) outputs.  If you have encryption-enabled Z-wave devices it will use AES encryption as well (e.g. door locks.)  It's fast, secure, and runs on extremely inexpensive hardware (the Pi2 and Pi3 computers) with the code itself and its entire working data set for a reasonably-large (~150 events) installation, plus a slave controller, requiring only 10MB of working RAM.  It consumes roughly 10-20% of a Pi2's CPU with it clocked at 600Mhz, or roughly "half-speed" and even with the FreeBSD operating system has nearly 3/4 of the 1Gb of RAM on the unit free.  In other words it's insanely economical in terms of resource consumption, is entirely self-contained in terms of security and it's also extraordinarily fast.

I've recently implemented an "app interface" on top of the standard, HTML-5 browser port that will make streaming-update apps (e.g. for Android) a trivial undertaking, and am starting development of a sample Android app to speak to it (which ought to be fun, since I need to teach myself Android app development in the process!)

Oh, and the license verification code (also certificate based using PKI) is built-in already -- it's literally ready to go, needing only the issuance of certificates to each customer for however long their license terms is.

So where is the firm or firms that want to offer a secure controller of this sort, whether as a packaged product or as an installed system complete with all the mark-up available to same?

If you're that firm email me at karl@denninger.net and let's talk.

Yes, it's for sale -- in source, all rights, and while it's not cheap the asking price is, for what it is, very reasonable.

View this entry with comments (opens new window)
 

Folks, let's make this easy.

Everyone wants to talk about how Podesta's email was penetrated, or the rest of the DNC, or that the RNC, allegedly, was not.

All the screamers are (still) out about  "Russia" and similar.

Let me restate -- while Podesta's email was apparently broken into via a "spearfishing" email (one with a reset password link embedded in it that didn't go to the real site, but rather to the person who was trying to steal) and which he was dumb enough to click and then provide his current password the real issue here isn't about this sort of attack at all.

The real issue is about the idiocy of such "email" systems or the use of any other sort of cloud provider for anything secure in the first place.

Let me explain.

I run my own email here.  It would be trivial for me to lock it down so that even if you stole my password it would be worthless.

How?

Simple, really.  You see on the same network I have a VPN gateway that does not accept passwords at all.  It only accepts a certificate.  Such a SSL certificate is (nominally) intended to sign and encrypt private emails, and can also be used as a secure identifier for a VPN.  It is, effectively, the same thing a server uses to secure web communications but with a different set of "intended use" flags set (client authentication and digital signature rather than SSL server authentication.)

All I'd have to do is change the configuration on the email system slightly so that only accesses that came from connected VPN clients could connect at all.

Now you'd have to steal a device and if you did, it would only work until I knew it was stolen (and revoked the key.)  No other means of getting in would work even with the password.

It is literally a 15 second configuration change on my Dovecot and Exchange servers to do this, and it would not impact my ability to exchange email with others one bit.

Modern smartphones (including Android, IOS and BlackBerry 10 handsets) can all use these certificates for an IPSEC/IKEv2 connection.  Such a connection can be "nailed" open as well, active even on cellular, or activated "on demand" by the user.  Modern commercial and freely available operating systems (Windows 7/8/10, MacOS, Linux and FreeBSD) can also use same.  Doing so positively encrypts all traffic coming into or leaving said device.

Such a system is extremely secure because only authorized devices, secured with a cryptographic key loaded on them, can see the service in question.  An unknown key is refused by the VPN gateway as is one that has been revoked. Only trusted certificates (which are loaded on the host in a certificate store) can connect.  I use this facility with other services here at Ticker Central so I can have my laptop with me and use it "as if I was at home" even from half the world away on an insecure, or even known to be monitored data link.

The only way to get packets onto the "private" network from the outside and thus be able to "see" the email store is to connect to the VPN and establish a tunnel and the only way to do that is to have a trusted certificate on the device in question.  No certificate, no connection, no access, password or no password -- period.

This sort of facility is essential if you intend to allow remote access to services that are themselves of questionable security (or worse) such as, for example, Windows file shares.

So why didn't the DNC do this?

Because it takes more than 30 seconds of thought to do it and in addition it means not using email providers like Google -- you have to do it yourself, in-house, or all these security steps are worthless since your certificates and such have to be where someone else, who is unvetted, can get at them.

In other words they were stupid, and so have been the others.  They chose the equivalent of an unlocked front door for their house, and then are surprised when someone walks in and takes all the beer out of the fridge.

Oh, and all the guns and money in the house too, along with the nice widescreen TV!

Just remember folks that these are the very same people who claim to be smart enough to run the country.

PS: All the cloud providers are unlocked houses.  Always. They have to be in order for a cloud service to work; it's not a choice, it's an inherent part of any public "cloud" architecture. Claims otherwise are like putting a 25 cent TSA lock on your suitcase and calling it "secure."  The reason you have not and will not see this discussed in the media, especially the "business media", is that the minute this fact reaches the level of general knowledge all of said "cloud providers" have their stock prices collapse.

View this entry with comments (opens new window)