[HN Gopher] Don't Look Up: Sensitive internal links in the clear...
___________________________________________________________________
Don't Look Up: Sensitive internal links in the clear on GEO
satellites [pdf]
Author : dweekly
Score : 512 points
Date : 2025-10-14 01:48 UTC (21 hours ago)
(HTM) web link (satcom.sysnet.ucsd.edu)
(TXT) w3m dump (satcom.sysnet.ucsd.edu)
| fennec-posix wrote:
| Section 6.3.2 is an eye-opener... good lord... Gets even worse at
| 6.4.2-3
| lambdaone wrote:
| It's absolutely jaw-dropping. Either no-one at these companies
| was capable of understanding the problem, or no-one cared
| enough to do something about it.
| throwing_away wrote:
| Likely both.
| yujzgzc wrote:
| From my time in similar companies, some people understand,
| and might care, but aren't empowered to do anything about it.
| They've got a job to do, and creatively auditing network
| security isn't it. Finding this kind of issue on the company
| clock won't get them promoted, on the contrary they'll look
| like they're slowing the team down with vulnerabilities to
| fix when they've got stuff to _build_ and _sell_. Very poor
| security culture.
| Arrath wrote:
| Am I offtrack in wondering if by reverse engineering the
| mentioned in-the-clear ATM communications you could (in theory)
| inject some malicious packets and in effect just dispense cash
| to yourself with a laptop and a dish? How very cyberpunk.
| dweekly wrote:
| Website: https://satcom.sysnet.ucsd.edu/
|
| Wired: https://www.wired.com/story/satellites-are-leaking-the-
| world...
| ROBLOX_MOMENTS wrote:
| Is it correct to Assuming the amount of Mexican companies in this
| paper is because of their receiver being in the major city
| southwestmost corner of the country ?
| jf wrote:
| That's my interpretation
| fennec-posix wrote:
| Yeah that's correct. The study was conducted in San Diego which
| falls under the satellite beam footprint required for services
| in Mexico.
|
| If you were in say, Alice Springs in Australia (wink wink) for
| example, you'd be able to see traffic for Indonesia,
| Philippines, most of South East Asia, and perhaps parts of
| China, South Korea and Japan if the beams are right.
| dylan604 wrote:
| > wink wink
|
| location location location is an apt phrase for more than
| just real estate
| bediger4000 wrote:
| I'm not so good at hints. Are you gesturing at the NSA
| facility at Pine Gap?
| mike_d wrote:
| Yes they are trying to be cheeky, but missing the mark.
|
| Pine Gap is a large facility for collecting data coming
| down from our own satellites.
|
| Foreign satellite collection in Australia happens at two
| other facilities:
| https://en.wikipedia.org/wiki/Shoal_Bay_Receiving_Station h
| ttps://en.wikipedia.org/wiki/Australian_Defence_Satellite_C
| ...
| N19PEDL2 wrote:
| And if you were in Harrogate, UK (more winks), you'd be in
| the footprint of satellites servicing Europe.
| dboreham wrote:
| You'd have a long walk to get to Menwith Hill.
| modeless wrote:
| > remarkably, nearly all the end-user consumer Internet browsing
| and app traffic we observed used TLS or QUIC
|
| There was a surprising amount of resistance to the push to enable
| TLS everywhere on the public Internet. I'm glad it was ultimately
| successful.
| vasco wrote:
| It was only successful because Google said you'd rank higher if
| you did it.
| yujzgzc wrote:
| It was only successful because of Let's Encrypt removing any
| excuse for not having HTTPS on your website, HSTS becoming a
| thing, and Chrome moving from gentle inducements (that cute
| green padlock) to nasty looking warnings if you didn't use
| encryption.
| vasco wrote:
| No, that was after, and it made it easy, but before google
| many people said there was no point "because their site
| wasnt sensitive". Those people didn't care about let's
| encrypt or how easy it was, they just didn't find a reason
| to do it. Google gave them a monetary reason to do it.
| stephen_g wrote:
| Which in-turn was driven by the Snowden revelations of what
| the NSA was doing in terms of mass surveillance.
| GuB-42 wrote:
| I have a more cynical view of the reason.
|
| It is to protect commercial interests, I don't think that
| Google cares about the NSA looking at your personal data.
|
| Google cares a lot about protecting the personal data they
| get from you, so that they and no one else can get it, at
| least not for free.
|
| Because let's get real, 99% of the time, why do you need
| encryption? The reason is commercial activity. It is really
| important to protect your credit card number, otherwise no
| one would trust e-commerce. For paid service to work, you
| need to authenticate, and it means encryption, no paywall
| means no authentication and much less need for encryption.
| And even with "free" services, you need encryption to
| protect the account that shouldn't even be required in the
| first place. As for general communication, my guess is that
| hackers and governments alike are more interested in
| financial data than in casual conversation.
|
| So by pushing TLS everywhere, Google is actually pushing
| for a more commercial, less open web. That it helps with
| general privacy (except against Google itself) is just a
| happy accident.
| kibwen wrote:
| This is remarkably naive for being self-admittedly
| cynical. Transmitting all web pages in the clear allows
| any man in the middle to spy on profile you based on the
| exact contents of the sites you're visiting. We know for
| a fact that ISPs were profiling us like this and
| monetizing this personal data prior to ubiquitous
| encryption.
| fragmede wrote:
| The even more unscrupulous ISPs would outright edit the
| HTML and images that got sent to you, removing Google's
| ads and injecting theirs. Which arguably Google would
| have cared about _a lot_ more.
| mike_d wrote:
| > I'm glad it was ultimately successful.
|
| What are you talking about? It was an absolute failure.
|
| As soon as we got widespread TLS adoption, Cloudflare magically
| came along and wooed all the nerds into handing over all the
| plaintext traffic to a single company.
| the8472 wrote:
| It has improved security, but it has made it less durable.
| Hosts now need constant maintenance to keep up with changes to
| TLS policies, certificate renewal protocols and so on.
| protocolture wrote:
| Had a vendor offer a customer of mine a huge discount if they
| purchased radios without the encryption license in the year of
| our lord 2024.
|
| Not even WPA or WEP. Just clear across the sky. And this is
| terrestrial.
|
| My bet is that in space there would be a noticable increase in
| heat/energy if they did encryption by default. But its still
| incredible to see them pretend like space is impossible to get
| to, ultimate obscurity.
| ryandrake wrote:
| Likely no consequences to the decision-makers for data
| exfiltration or other shenanigans happening, so there's nothing
| motivating a behavior change.
|
| The reason security is so bad everywhere is that nobody gets
| fired when there's a breach. It's just blamed on _the hackers_
| and everyone just goes on with life singing "We take security
| very seriously--this happened because of someone else!"
| chii wrote:
| > nobody gets fired when there's a breach
|
| this must mean the consequences of such a breach has either
| not produced any visible damage, or the entity being damaged
| is uncaring (or have no power to care).
| ryandrake wrote:
| Or, the entity being damaged is not the decision maker and
| has no power to hold the decision maker responsible.
| josephg wrote:
| End user license agreements are a huge part of the problem.
| Ideally users could sue if our data is leaked - and the
| threat of being sued would put pressure on companies to
| take security more seriously. Ie, it would become a
| business concern.
|
| Instead we're constantly asked to sign one-sided contracts
| ("EULAs") which forbid us from suing. If a company's
| incompetence results in my data being leaked on the
| internet, there's no consequences. And not a thing any of
| us can do about it.
| astrange wrote:
| There is in at least California, the EU, and China. A lot
| of clauses in EULAs aren't actually legal.
| devjab wrote:
| On the other hand you can't sue a company for losing your
| data in many EU companies. You can report them to
| whatever data protection agency your country has, and
| after an investigation they can fine, and/or, in more
| serious cases turn the matter over to the police for a
| criminal investigation.
|
| The disadvantage of this is that the local data
| protection agencies haven't been handing out very big
| fines. Sometimes that's due to company law. In my country
| you'd fine the owning company, which in many cases will
| be a holding company. Since fine sizes are linked to
| revenue and a holding company typically has no revenue,
| this means fines are often ridicilously small.
| lmm wrote:
| Or the damage is diffuse whereas the costs of preventing
| the breach would be concentrated. Or the connection between
| the damage and the breach is difficult to prove.
| protocolture wrote:
| >this must mean the consequences of such a breach has
| either not produced any visible damage
|
| Yeah lets say you were carrying unencrypted frames for
| Bills Burger Hut.
|
| The largest extent of the damage might be sniffing some
| smtp credentials or something. Bill sends some spam
| messages, never figures out how it was done but their IP
| reputation is always in the toilet.
|
| Lets then say instead of Bills Burger Hut, you are carrying
| traffic for critical mineral and food industries. The
| attacker isnt a scammer, but a hostile nation state.
| Customer never realises, but theres a large, long term
| financial cost because (TOTALLY NOT CHINA) is sharing this
| data with competitors of yours overseas, or preparing to
| drop your pants in a huge way for foreign policy reasons.
|
| No one gets fired until after the worst case long term
| damage, and even then probably not.
|
| In fact, the likely outcome is that the burden gets moved
| to the customer for L2 encryption and the cowboy never
| changes.
| ozim wrote:
| If you fire people for stuff they didn't maliciously
| introduced you will end up with no people to work with.
|
| Imagine jailing doctors for every patient that died you
| would be out of doctors quite soon.
| necovek wrote:
| The legal system already has sufficient cop-out: for
| anything that you should have been aware of, or would
| have been informed about.
|
| Eg. doctors do get sued and fired for malpractice, if
| they did something no other skilled doctor would
| reasonably do ("let's just use the instruments from the
| previous surgery").
| sayamqazi wrote:
| Here are a bunch more things to make you even more
| scared.
|
| - Oops! mistakenly left some instrument inside and sewed
| up the patient - Junior begging to do certain step of the
| surgery while the anesthesiologist asking them to just
| get a move on. - Administered a drug to a newborn baby
| which was supposed to be given to the mother. (My
| sister's colleague did this with no consequences)
| nkrisc wrote:
| If the doctor is criminally negligent they could be
| jailed.
| ozim wrote:
| That's kind of obvious, I didn't think it has to be
| spelled out.
| nkrisc wrote:
| My point is that something doesn't have to be malicious
| to be criminally negligent, if the law says so. I'm
| suggesting that some of the security breaches we've seen
| ought to have been criminally negligent. Perhaps they
| weren't under existing law, but I think they ought to be.
| sayamqazi wrote:
| My sister knows a doctor who botched a surgery due to an
| argument with a junior who wanted to do some step of the
| surgery. The senior one was not having it at all and just
| threw the scalpel directly at him. Nothing happened to
| him because if we start firing doctors for this, we would
| be missing out on all the surgeries he did successfully.
| fn-mote wrote:
| > Nothing happened to him
|
| There is a world of difference between "nothing happened"
| and being fired. Just like in the NBA, a fine (monetary
| penalty) of a sufficient size will get someone's
| attention without losing their skills forever.
| nakedper wrote:
| We don't get delivered to us 18-year-olds that happen to
| be in perfect health. And a lot of Americans don't
| believe in wellness visits. Although more and more it's
| the insurance companies that are practicing medicine.
| Sorry it's a sore subject with me lol
| devjab wrote:
| Who do you imagine will get fired? The CISO who's been
| recommending various security imporvements and been trying to
| get them implemented, but been unable to do so due to a lack
| of C level interest in IT. Or the C level's who lack interest
| in IT security until it bites them in the investor?
|
| At least here in the EU we're moving toward personal
| responsibility for C level's who don't take IT and OT
| security serious in critical sectors, but in my anecdotal
| experience that is the first time anything regarding security
| has actually made decision makers take it serious. A lot of
| it is still just bureaucracy though. We have a DORA and NIS2
| compliant piece of OT that is technically completely insecure
| but is compliant because we've written a detailed plan on how
| to make it secure.
| gremlinunderway wrote:
| Who currently gets fired due to engineering malpractice? It
| would be the same thing if there was actual certifications
| and engineering sign-offs in cybersecurity or other
| critical areas of development.
|
| I wont pretend that accountability in the physical
| engineering world is all smiles and rainbows but at least
| there are actual laws dictating responsibilities,
| certification and other real consequences for civil
| engineers. When a Professional Engineer in Canada signs-off
| (seal) on work they are legally assuming responsibility
| which means the practitioner could be held accountable in
| the event of professional misconduct or incompetence
| regarding the engineering work. There is no reason but
| corporate greed and corruption why there isn't similar
| legislation in North America for cybersecurity or software
| engineering where you have professional bodies certify
| people to be legally obligated to sign-off on work (and
| refuse work that isn't up to standards).
|
| But this would require introducing actual legislation which
| god-forbid how could we do such a thing to the poor market!
| It would stifle their innovation at leaking everyone's
| data.
|
| There's no reason we couldn't extend the same existing
| system of licensure [1] that professional engineers
| require.
|
| Sure maybe its overkill for someone stringing together a
| python app, but if you're engineering the handling of any
| actual personal information then this work ought to be
| overseen by qualified, licensed and accountable
| professionals who are backed by actual laws.
|
| [1]https://en.wikipedia.org/w/index.php?title=Regulation_an
| d_li...
| notmyjob wrote:
| That and h1b abuse.
| mjevans wrote:
| Why does Space need to decrypt a vast majority of the traffic?
| Flow can be just as brick not-smart as fiber optic cables under
| the sea.
|
| Now, management, control, etc? Yeah those you need to decode in
| orbit.
| JumpCrisscross wrote:
| > _Flow can be just as brick not-smart as fiber optic cables
| under the sea_
|
| Wouldn't this still leak metadata for routing?
| etiennebausson wrote:
| It would not be perfect, but it wouldn't be purposefully
| shooting oneself in the foot.
| lxgr wrote:
| Depending on the spot beam size, the only thing you'd
| always learn is the ground station's rough geographic
| location.
|
| Anything else could be masked by metadata encryption,
| rotating lower layer identifiers, and cover traffic. Not
| sure if any actual protocols do that though.
| dooglius wrote:
| The encryption of the payload doesn't need to take place on the
| satellites
| protocolture wrote:
| Thats very true.
| astrange wrote:
| Encryption is basically free as far as I know, but it is more
| complex and it must be hard to get software updates up there.
| trenchpilgrim wrote:
| It is almost free on modern CPUs that have hardware
| acceleration, yea
| tgsovlerkhgsel wrote:
| Wireguard uses ChaCha20, which to my knowledge neither has
| nor requires HW acceleration to be fast.
| lxgr wrote:
| It's faster on CPUs without dedicated hardware than AES,
| but that doesn't mean that it's faster than fixed-
| function AES hardware.
| fragmede wrote:
| > However, the software performance [of wireguard] is far
| below the speed of wire.
|
| https://github.com/chili-chips-ba/wireguard-fpga
| 15155 wrote:
| Space-faring electronics aren't exactly cost-sensitive -
| the cost of a cluster of crypto-accelerated CPUs or rad-
| hardened FPGAs is peanuts compared to the human and launch
| costs that go into these satellites.
| blackoil wrote:
| Issue is the satellite was launched 10 years ago with
| 20-year-old tech. So, calculations of today may not be
| applicable on them.
| fransje26 wrote:
| Here is their excuse:
|
| > Panasonic told us that enabling encryption could incur a
| 20-30% capacity loss. In addition, when using IPsec, ESP and
| IP headers can introduce 20-30 bytes of overhead, which is
| nontrivial for small-packet applications like VoIP and video
| calls
| lxgr wrote:
| > Panasonic told us that enabling encryption could incur a
| 20-30% capacity loss.
|
| Wow, I guess they're still betting on customers sending
| tons of redundant data up/down that they can shave off via
| compression? That's such a 90s modem thing to do. ("Faster
| than 56 kbit/s!!")
| tgsovlerkhgsel wrote:
| > My bet is that in space there would be a noticable increase
| in heat/energy if they did encryption by default.
|
| Why would it? The data originates from earth, and should be
| encrypted during the uplink leg too, so the crypto should all
| happen in the ground segment (or even well before it reached
| anything that could be considered part of the satellite setup,
| honestly).
| lxgr wrote:
| Exactly, and the little bit of data actually destined for
| satellites - which includes momentum wheel and booster
| control - is something you'll definitely want to at least
| authenticate.
|
| I believe that's one of the few things that even amateur
| radio operators are allowed to encrypt for that reason.
| anilakar wrote:
| Satellites have long lifespans and have to outlast current
| crypto algorithms. Ideally they're nothing more than radio
| repeaters that rebroadcast the uplink signal.
| ptero wrote:
| That seldom works. Simple repeaters transmit the strongest
| signal they get and can be easily hijacked by a rogue
| ground transmitter. This is the main reason simple
| repeaters on orbit went out of fashion in the 1980s.
| lxgr wrote:
| Really depends on what the satellite does, and even for
| purely "dumb pipe" satellites you'll need some telemetry
| for stationkeeping, repositioning etc.
|
| Practically, you'll also want to be able to reconfigure
| spot beam to backhaul mappings or even cross-connect some
| spot beams to cut satphone-to-satphone voice latency in
| half etc.
|
| That's not even considering constellations like Iridium
| that do actual packet switching in space.
| polski-g wrote:
| Correct. That is what almost all geostationary satellites
| are. If you want encryption, do it at the application
| layer.
| Thorrez wrote:
| The only thing I can think of is maybe the satellite company
| runs compression on the data. Encryption would prevent that.
| XorNot wrote:
| I mean a bunch of those crypto systems turn out to be flawed
| though. So skipping the vendor implementation and using
| something in software instead could make sense.
| feraloink wrote:
| The landing page has a Q&A. This is the relevant part of the
| response to the question, "Why aren't all GEO satellite links
| encrypted?"
|
| >Encryption imposes additional overhead to an already limited
| bandwidth, decryption hardware may exceed the power budget of
| remote, off-grid receivers, and satellite terminal vendors can
| charge additional license fees for enabling link-layer
| encryption. In addition, encryption makes it harder to
| troubleshoot network issues and can degrade the reliability of
| emergency services.
|
| So, the only suggestion that there would be greater heat/energy
| if they did encryption by default is the part about decryption
| (receiver) hardware having limited power budgets in some cases.
| There's more than what I copy-and-pasted above, but the overall
| message is that lots of organizations haven't wanted to pay the
| direct costs of enabling encryption... although they should.
|
| EDIT: Link to Q&A https://satcom.sysnet.ucsd.edu/#qanda
| lambdaone wrote:
| It's not a spacecraft issue. Encryption can be done at the
| ground stations, and mandated as part of the standards for
| interfsce equipment, just like with DOCSIS. There's nothing,
| physically, to stop you passing unencrypted traffic down your
| DOCSIS cable, if you wanted to make a nonstandard modem and
| send unencrypted traffic on your local physical segment of
| the network. But the rest of the network will refuse to talk
| to it.
|
| The same could have easily been mandated for satellite links
| - no encryption, your packet won't get forwarded to the
| internet at the ground station, and any packets sent to you
| from the internet will be sent to you encrypted. And all this
| can be implementd without needing to touch the satellite
| itself, which will continue to forward what it sees as
| unencrypted traffic without any design changes. It could even
| have been implemented incrementally on existing running
| services, with old and new equipment working side-by-side,
| but all new ground stations required to support encryption,
| and with a sunset date for old equipment, and a rolling
| upgrade program.
|
| DOCSIS got this right in 1999; the satellite industry has had
| 25 yeqrs to catch up.
| lambdaone wrote:
| Absolutely mind-boggling that this is a thing; not just that
| satellite links aren't per-user link-encrypted, but also that
| people are still using unencrypted protocols to exchange
| sensitive information on the public internet in 2025.
| dylan604 wrote:
| As with anything in life, when it's what you know and do on the
| regular, that simple thing can look like magic to others. I met
| an old timer in the satellite business that came out to help
| install our receiver for a new TV channel the company I was at
| was getting off the ground. He found out what bird we were using
| and what its slot was. Based on that, he knew how many satellites
| over from the satellite he knew and used as his base. It was a
| long time running TV channel that he could find very quickly.
| Once that bird was located, he just manually (literally pushed
| the dish with his hand) counting the number of satellites that
| came in/out of view until he landed on "our" bird. Once there,
| connected our receiver and baddaboom baddabing, there it was.
| Once the satellite was pointed at the proper angle to the south,
| it took less than five minutes from him connecting his receiver
| to verify his base signal to packing up and heading off the roof.
|
| His base satellite signal was unencrypted and a main reason he
| used it for this purpose. Our channel was scrambled, and only
| verifiable after our receiver with the decoder was connected. It
| was impressive seeing someone that good at their job make it look
| so easy, but after he explained the layman's version of orbital
| slots it became less magical. This is why magicians are meant to
| not tell you how the trick is done.
| stavros wrote:
| Eh I kind of feel like you can't say that. If something is
| magical before you learn how it's done, it should be magical
| after. The magical part isn't "it's actually impossible", but
| "it's so far from what I could come up on my own", which still
| holds after you know the secret.
| lxgr wrote:
| Yes, some excellent magic tricks work even better when you
| know how they work, especially if they're the kind that's
| based on putting in ridiculous amounts of work or
| skill/practice.
|
| Penn and Teller play a lot with that idea, for example.
| padjo wrote:
| You should hide the secret if it's ugly, but you can expose
| if it's beautiful (and it's your trick!)
| rglover wrote:
| This story gave me an odd burst of hope, thank you.
| wyager wrote:
| I see no issue with the satellite backhaul itself being
| unencrypted; anyone using the satellite provider should assume
| they're hostile and encrypt+authenticate everything they send
| anyway. I don't trust my ISP's fiber to be snoop-resistant just
| because they nominally have some shitty ONT encryption.
|
| Obviously the specific examples of end-users failing to encrypt
| are bad, but that's not really a problem with the satellites.
| varenc wrote:
| If someone is browsing the internet on in-flight wifi, and
| their DNS requests get leaked this way, I don't really think
| its the casual airline user's fault for not encrypting their
| DNS traffic. Modern cell phone data traffic (4G/5G) is all
| encrypted, so the same unencrypted DNS requests can't just be
| passively sniffed. Something similar should happen here.
|
| I'd blame the airline or their ISP provider for sending
| unencrypted traffic through the air like this. Not the
| satellite, but its top level customer. There's a big
| difference, IMHO, between your ISP being able to sniff your
| fiber traffic, and your traffic being observable from ~30% of
| the globe.
| jeffrallen wrote:
| It is the fault of the end user software not protecting them.
| This is why we have encrypted SNI (promoted by Cloidflare,
| for example).
| mike_d wrote:
| I don't know if you've ever tried to actually use in flight
| wifi, but any traffic not subject to inspection is heavily
| throttled to the point of being unusable.
|
| ESNI is also a technology in search of a problem. It does
| not provide any meaningful security benefits.
| jeffrallen wrote:
| This. Bytes on every medium can be snooped. Internetworking
| means that your bytes go on mediums you don't know about and
| don't control. There's no such thing as a link where encryption
| is not needed, except localhost.
| dsab wrote:
| I was working in space industry and ECSS security guidelines are
| missleading grant seeking startups to try to reinvent TLS on
| orbit. There are to mamy bureaucracy. ECSS guidelines for
| software teams were created by people who never written a Hello
| World in their life, just look at specs of ECSS Packet
| Utilisation Service, it's a joke, that's why I prefer to work for
| VC funded companies than grant funded.
| vayup wrote:
| Some of the stuff that was extracted from the unencrypted traffic
| in the link:
|
| - T-Mobile backhaul: Users' SMS, voice call contents and internet
| traffic content in plain text.
|
| - AT&T Mexico cellular backhaul: Raw user internet traffic
|
| - TelMex VOIP on satellite backhaul: Plaintext voice calls
|
| - U.S. military: SIP traffic exposing ship names
|
| - Mexico government and military: Unencrypted intra-government
| traffic
|
| - Walmart Mexico: Unencrypted corporate emails, plaintext
| credentials to inventory management systems, inventory records
| transferred and updated using FTP
|
| This is insane!
|
| While it is important to work on futuristic threats such as
| Quantum cryptanalysis, backdoors in standardized cryptographic
| protocols, etc. - the unfortunate reality is that the vast
| majority of real-world attacks happen because basic protection is
| not enabled. Good reminder not take our eyes off the basics.
| CGMthrowaway wrote:
| Is there a git repo that lets one read this stuff in real time
| yet?
| zelos wrote:
| > Real-time military object telemetry with precise geolocation,
| identifiers, and live telemetry
|
| Oops
| NoiseBert69 wrote:
| _Pulls out the bamboo whip_
|
| Another round of OpSec training
| atoav wrote:
| Why? I thought we are now clear on OpSec?
| 1oooqooq wrote:
| that message was about the inner circle of the regime, to
| discuss the plans to sabotage opsec elsewhere.
|
| anyway, but even that had a joke of opsec.
| misswaterfairy wrote:
| Perhaps not _in_ the clear for OpSec purposes...
| alfiedotwtf wrote:
| > This is insane!
|
| Not as insane as it was in the early 2000s...
|
| > while link-layer encryption has been standard practice in
| satellite TV for decades
|
| Before Snowden, I would say 99% of ALL TCP traffic I saw on
| satellites was in unadulterated plain-text. Web and email
| mostly.
|
| ... the pipe was so fast, you could only pcap if you had a SCSI
| hard drive!
| T3OU-736 wrote:
| ```... the pipe was so fast, you could only pcap if you had a
| SCSI hard drive!```
|
| This is why NSA asked for (and got from SGI) a guranteed rate
| I/O API - to make sure that whstever the signal intelkigence
| platform sensors captured could be written to storage.
| petercooper wrote:
| I was exposed to some of this as a teenager due to a (now
| dead) family member being heavily into telecoms. You could
| receive and process POCSAG (the protocol used by paging
| systems) to pretty much read the entire stream of
| unencrypted, plain text pager messages going out over the
| wire. You could also reprogram a generic pager to receive
| pages for whatever number you liked. You could also transmit
| your own POCSAG and send any number a page (only within your
| transmission range).
|
| SMS was also a bit like this in its early days and you could
| read them coming off the local cell (also true of calls at a
| certain time, but I didn't see much of this).
|
| I just did a quick search and apparently many pagers in the
| UK are still running cleartext POCSAG! https://www.reddit.com
| /r/RTLSDR/comments/1asnchu/are_uk_page...
| tmjwid wrote:
| Yeah POCSAG is not encrypted here in the UK. You can still
| see all the emergency information from around the country
| unencrypted in realtime. They even broadcast the details of
| the emergency and a lot of times it's not nice. You do/did
| get some bird watching sightings though!
| sidewndr46 wrote:
| This is still the case today in the US, plenty of pager
| systems run POCSAG or near equivalents. There is no
| conditional access or encryption of any kind. Receiving
| such signals is notionally criminal, but I'm unaware of any
| prosecutions for such a thing.
| feraloink wrote:
| In https://satcom.sysnet.ucsd.edu/ Has The Issue Been Fixed
| section:
|
| >we re-scanned with their permission and were able to verify a
| remedy had been deployed: T-Mobile, WalMart, and KPU.
|
| The fact that critical infrastructure (e.g. utility companies
| using satellite links for remote-operated SCADA) was exposed is
| really scary too.
| colechristensen wrote:
| >The fact that critical infrastructure (e.g. utility
| companies using satellite links for remote-operated SCADA)
| was exposed is really scary too.
|
| Really serious security risks in critical/industrial
| infrastructure are ... numerous. And these aren't complex
| vulnerabilities, these are leaving the door open with default
| passwords, unencrypted traffic, and that sort of thing.
| jabiko wrote:
| When driving by Bad Aibling I always wondered why the BND
| (intelligence agency) invests so heavily in satellite
| communication eavesdropping. I naively assumed that this kind
| of communication would be encrypted.
|
| Also a fun fact: For a long time it was only semi-officially
| known that the BND owned and operated the site. Officially it
| was called "Long distance telecommunications station of the
| Bundeswehr" and operated by the "Federal Office for
| Telecommunications Statistics"
| MagnumOpus wrote:
| At least since the mid-1990s Echelon revelations in the EU
| parliament anybody who cares knows that Bad Aibling (and
| similar stations all across Europe like Bude/Morwenstow in
| the UK) had been operated by the NSA in collaboration with US
| Army intelligence (if the official name of "18th United
| States Army Security Agency Field Station" didn't clue you
| in.
|
| Officially it has been transferred to the BND; experience
| suggests all data from there still goes straight back to Fort
| Meade... (And in exchange the BND gets some morsels back on
| people _they_ are not allowed to spy on publicly.)
| RajT88 wrote:
| I'm waiting for IT departments worldwide to wake up to the
| threat that your browsers are leaking all of your URI's by
| default back to the manufacturers.
|
| URI's leak company secrets. I'm sure there's some people at
| Google using Edge which are leaking company data to Microsoft.
| I'm sure there's some people at Microsoft using Chrome which
| are leaking data to Google.
|
| Edge and Chrome both send back every URI you visit to "improve
| search results" or to "sync history across devices". It's not
| clear if this includes private mode traffic or not (they don't
| say).
|
| Huge privacy hole to allow this, and nobody seems to be aware
| or care.
| pengaru wrote:
| Wait til you hear about how many companies willfully perform
| all their work in g-suite and office 365/teams
| RajT88 wrote:
| Indeed. And they are trying to find sneaky ways to get you
| to back up more and more data there.
|
| They do have privacy policies which say they won't sell
| that data, or use it for advertising or anything other than
| delivering the service. But - who knows if that is true?
| There's no oversight. And if they get caught breaking that
| privacy policy, who has the appetite these days to do
| anything meaningful in terms penalties? Nobody.
| shadowgovt wrote:
| I believe the point of the above comment is "The trust
| model already trusts the recipient, so nobody cares that
| the recipient is seeing query params because they trust
| the recipient to ignore them."
|
| > who knows if that is true? There's no oversight
|
| The oversight is that those companies rely heavily on
| being trustworthy, and proving untrustworthy would be
| disastrous for their business models. Companies don't
| have to care right now because they have reason to
| believe Google, MS, et. al. _aren 't_ sniffing that data.
| If they came to believe they were?
|
| Google alone is making $43 billion on Cloud and would
| prefer not to jeopardize that revenue stream.
| RajT88 wrote:
| > If they came to believe they were?
|
| That's what I don't get - security and compliance people
| are paranoid.
|
| This is the kind of thing they shouldn't be requiring
| evidence to care about, given the rest of their job is
| about the "what-ifs". Just seems crazy to me.
| abdullahkhalids wrote:
| Facebook for example has been shown in multiple public
| scandals and lawsuits to be untrustworthy. It is still
| among the largest social media platforms, and many
| businesses, for example, reveal large chunks of their
| marketing strategies to Facebook through its advertising
| tools.
|
| The reason why this does not result in a significant loss
| of usage is because trustworthiness-usage is not a linear
| function or a even a continuous function -- it is a step
| function. To cause less usage, the loss-of-trust force
| has to be higher than the networking effect force.
| Otherwise, behavior does not change.
| nakedper wrote:
| WHEN they get caught and the fine never outweighs the
| sale price of the data. It's not a coincidence. It's a
| clear factory in the cost of doing that into business.
| There's no Moreland ethical backbone here.
| atarvaneitor wrote:
| Does anyone remember the days when you pointed a 60cm antenna at
| the Hispasat 30W and connected your DVB-S2 tuner in Windows,
| Using Crazycat's BDADataEx, you tuned an IP data transponder.
| Using a technique called Satfish (with a software I don't
| remember), some files were reconstructed, usually vsat data from
| oil platforms... and porn.
|
| I'm going to dust off the TBS DVB-S2X card and try to find a data
| transponder to test the DontLookup app.
| https://github.com/ucsdsysnet/dontlookup
|
| Where I live, it's almost impossible to find any interest in FTA
| or pirated SAT TV.
|
| att: ham radio operator interested in satellite radio :D
| myself248 wrote:
| My understanding has been that the majority of FTA TV in the
| western hemisphere is religious in nature, and that's simply
| not a tempting onboarding bait for a lot of people to buy the
| gear and start exploring. The vast majority of satellite TV
| receivers in the US are propretary VSAT services, not equipped
| for exploring wild feeds and things.
|
| My understanding is that elsewhere, there's a lot more
| interesting stuff FTA so a lot more people have the hardware,
| and the hardware itself is more generic. So there's just more
| opportunity for someone to get bored and discover a new hobby a
| few degrees to the side of their usual watering hole.
| drsopp wrote:
| I wonder why the DOI link on the bottom left of the first page
| does not work:
|
| https://doi.org/10.1145/3719027.3765198
| xucheng wrote:
| It's quite common for a DOI to be assigned to a paper after
| it's accepted during camera ready. However, the DOI won't work
| until the conference or journal version is published on the
| official website (ACM in this case). The version you're viewing
| now is simply a preprint directly from the authors.
| feraloink wrote:
| Exactly! It says this as one of the 3 reasons for DOIs not
| found on the error page:
|
| >The DOI has not been activated yet.
| jeff_lee wrote:
| Who needs hackers when companies broadcast their secrets to half
| the planet?
| immibis wrote:
| Intercepting non-obvious (in the sense that you can't just,
| like, open your wifi menu and see them) broadcasts is still
| hacking. Heck, even intercepting obvious (in the sense that it
| says "your data is not secure" on the screen of the people
| communicating) broadcasts is still hacking. Doing what
| Firesheep does, before Firesheep, was hacking. And then someone
| made Firesheep and it was still hacking, but now anyone could
| do it by clicking a few buttons, without any hacking skill
| whatsoever, not even using a command line, so it was finally
| patched.
| metalman wrote:
| I think that the risk of anybody achiving a malicious outcome by
| accessingn these data streams is as spectacularly low as the
| effort required to get the signal and then figure out some
| context to the randomised transmissions and then weaponise that
| is high, very high. Presumably it is GB/sec by however many
| channels, 99% of it will dry your eyeballs out and quickly render
| even the most determined spook a quaking quivering mess huddled
| in the corner of an office screaming " make it stop" the
| researchers behind this are just showing off, but I will bet any
| money, nothing but nothing could keep them there going through
| the worlds slop, which a smart, counter spook would insure was a
| regular and tantilising portion of the signal to begin with. the
| issue is that these sattelites are just repeaters, and there is
| little ryme or reason to the content, and personel good enough to
| work it, can find much much more profitable things to do.
| BertoldVdb wrote:
| A lot of low population density cellular backhaul runs over
| satellite. Two factor SMS or voice can be directly intercepted,
| assuming encryption is not used.
| OnACoffeeBreak wrote:
| From the Introduction: "Each satellite may carry traffic for
| dozens of independent networks through an array of on-board
| transponders, each covering a diameter of thousands of kilometers
| (at most a third of Earth's surface)".
|
| Can someone help me understand the use of "diameter" in this
| sentence. I am guessing it refers to the satellite's signal
| coverage of the Earth's surface. If that's the case, wouldn't
| something like arc degrees be a better measure? I just can't
| figure out how "diameter" can be used to describe a coverage arc
| or area.
| jnovacho wrote:
| They mean the intersection between the cone produced by the
| satellite and "illuminated" surface. If the antenna beam is
| normal to the sphere, it will produce a disk which has an
| diameter.
| slow_typist wrote:
| This, and 1/3 of earth's surface is the maximum you can see
| from geostationary orbit.
| BonusPlay wrote:
| If you're interested in the topic there's great YouTube channel
| that demonstrates such attacks IRL together with full tutorials.
| Below are 2 satellite related videos:
|
| 1) https://www.youtube.com/watch?v=2-mPaUwtqnE
|
| 2) https://www.youtube.com/watch?v=ka-smSSuLjY
| bschne wrote:
| Tangential, but I was very surprised to learn recently that my
| country still has a more or less nationwide POCSAG pager network
| where only some users encrypt their traffic
| elevation wrote:
| As an aside, the PDF metadata says it's generated from LaTeX, but
| the layout and typesetting looks better than the LaTeX output I'm
| familiar with. Nicely done.
| bobbylarrybobby wrote:
| The body font appears to be Libertinus Serif (and I assume
| Libertinus Sans is the seldom-used sans font), which I agree
| look much nicer than the default Computer Modern
| vzaliva wrote:
| In view of this disclosure I am even more dissapointet T-mobile
| satellite service (via starlink) does not support Signal
| messenger.
| klaff wrote:
| Ah, this brings back memories of listening to long-distance phone
| calls using a C-band dish and a general coverage (aka shortwave)
| receiver. Voice channels were placed on single-sideband channels
| between roughly DC and 6 MHz, and that whole set of signals was
| transmitted to the particular satellite transponder just like a
| video signal would be. The dish receiver couldn't decode that but
| it had a subcarrier output intended for accessories (stereo
| decoders maybe?). By plumbing the subcarrier output to the
| antenna input of the shortwave radio you could dial around to
| individual voice channels. I could only hear one side of the
| calls, but it was still very enlightening. I heard a number of
| mundane conversations, one drug deal, and a woman cursing in ways
| I'd never heard before. This was pre-internet and I was an
| impressionable kid - maybe 13 or so. Fun times.
___________________________________________________________________
(page generated 2025-10-14 23:01 UTC)