Agreed. I couldn't figure it out at all without navigating around a bit. Someone with some HTML/CSS ability should attempt to donate some time to fixing this web page's messaging issues to get the product across better, to those technical or otherwise.
> political freedom from authority is only ever won via extreme violence.
Eh, that's the most extreme end. Political freedom from authority is won by having more power, period. That power can come in many forms, but at its most primal can come from having the capability of lethal force. The power of a representative government is supposed to be in being able to vote out those that are destroying you, not in you having to take up arms to solve the issue.
Nope, I'm not thinking of WPA/WPA2; I'm just destroyed here by a lack of my own ability to properly communicate things sometimes.
At the high level, "SSL" is a term for an obsolete standard that encrypts connections, protocols be damned, supplanted by the term and the protocol changes that make up TLS. WEP is an obsolete standard for encrypting wireless connections (so is WPA), and WPA2 is the newest version. However, often we'll hear technical and non-technical people talk about how they implement "SSL" even though that's not technically the correct term to use anymore. Rarely do people use "WEP" to mean WPA.
> If you do a lot of network infiltration, these boxes are among the most useful targets; unlike routers running JunOS, the VPN concentrators have a large outside-the-packet-filter attack surface, and everyone runs them.
Don't forget that the newer SRX-series VPN gateways are JunOS-based, and seem to be recommended by most Juniper sales people these days. There are certainly a ton of ScreenOS devices, but Juniper seems to have mostly deprecated them in their messaging.
The primary Juniper security track certifications are JunOS-focused, and there's only a basic specialization available from them for ScreenOS. Juniper has mostly staked their future on JunOS from what I can tell.
Seriously. I can understand non-engineering-types calling SSL "SSL" still, but there's a point at which I will begin to date or discredit people's knowledge of "SSL" if they're still referring to it as such (and not to one of the libraries like polar, open, boring, etc.) I don't generally like being a pedant, but SSL and TLS are different things that attempt to solve the same problem, much like WEP and WPA. Most people don't call WPA WEP anymore.
> Overall, resilient public cyber key terrain could prove a double-edged sword: enabling DoD to project power, both in terms of information as well as cyberspace operations, but also enabling enemies of the United States to do the same, and with a lower barrier of entry than before.
I think you could argue this is a bit what the government already thinks of the Tor Project, although they call it 'loosely decentralized'.
I seriously whether or not politically we will actually head down this path; which each successive government I'm beginning to see the fear that cypherpunk-utopia, anarchocapitalist-style decentralization may bring to nation-states and the risks inherent to some citizens in that process.
From a politician's (very misguided) view of laws solving problems, it's easy to smash the "resilient public cyber key terrain", while still getting the edge of the sword you want (allowing these technologies to provoke unrest in countries you don't like) - you pass laws that ruthlessly enforce the use of Tor et al on your own territory, run a lot of psychological operations against the use of those tools by your citizenry, and then spread the shit out of that same technology through covert channels to everywhere else in the world, for those ballsy enough to be "separatists" in their own countries. The politician will think that assuming a powerful security organization and steep enough penalties domestically, you can probably eke a net benefit out of the technology outside of your nation-state with little downsides within you own.
This leads to a scary way of blunting the edge of the sword that a politician thinks could hurt them domestically, and I'm afraid that perhaps in some ways we're going down that path (RIPA 2000 is a good example of that, any type of forced-key-disclosure type of thing, or any type of key escrow and tying laws to requiring key escrow.) In the end it doesn't really work, but it does shed a lot more blood in the process.
As a follow-on question: was NetScreen using Dual_EC_DRBG before Juniper bought them (and with it ScreenOS?) If so, it might be good to scrutinize the original NetScreen owners and where they are now (hint: They now run Fortinet and Palo Alto Networks. Are they at risk of interesting, compromised security choices, now, too?)
And you're right. Juniper could still have their own e, which renders the security pointless.
I'd like to argue Snowden is as pure as many of us wish he was in this case, but he, too, must unfortunately play the games of the nation-states that are more powerful than him.
Snowden is right in talking about MTProto's issues, and this is a case where he can talk about something both he and the Russian government dislike, albeit for different reasons. It's a fine line to walk to maintain integrity.
Why the statement from Juniper, then? To try to CYA so they don't end up looking as shitty to the community as RSA did post-bribe?
EDIT: The conspiracy theorist in me would say "this is intentional, too." Changing a value to 31 from 32, or adding a single global assignment in a different function, wouldn't be caught on first review most likely, especially since where the '31' is, 31 is also used all over the code to refer to X9.31.
Don't sell JunOS short. It is far more complex than "software networking on BSD" and has a lot of proprietary bits.
Junos (FreeBSD) is the Routing Engine; Juniper hardware also contains an ASIC-based Packet Forwarding Engine, which loads microcode from the Routing Engine upon boot. Not everything's in Junos all the time, but since the PFE loads its embedded OS from the Routing Engine kernel, you could just pwn the Routing Engine and then also have some sense of persistence in the PFE on reboot, probably. I don't know much about how the PFEs work internally.
I'm certainly no FreeBSD/JunOS expert. I am an unabashed fanboy of JunOS's *nix-y structure, though, vs. the monolithic binary that is IOS. (There was a great Blackhat 2011 talk on IOS reverse engineering, if you are interested in that sort of thing. [1])
I am eagerly awaiting the incident report on this, although I find it unlikely we'll ever hear anything more than this from JTAC and friends. If this is the work of an intelligence agency, it will likely be gagged under the guise of "national security" unless there's a press-worthy indictment coming out of it.
The MSFT Visual .NET tools are probably the most visual you can get and still be productive.
One of the things I really like about beginners having interface builders is that they can bridge the context between the code and the user interface in a way that is more meaningful than you get out of even web applications. To get started building interactive prototypes, you can draw first and flesh it out later, vs. learn how to draw in markup/code and then learn how to glue it together.
Some of my earliest memories of finding real accomplishment in programming were using Visual C++ and Visual Basic. While I had written a ton of absolute crap in BASIC and C before, the toy projects were relegated mostly to scripts and whatever text or ANSI interfaces I could dream up. I felt like I had made something accessible to other people. Also, my UI design skills got 1000 times better when I had an easy, accessible way to approach user-oriented design simultaneously with the behavior, and it helped me better learn how to divide my code up in ways that made sense.
Hoo boy, most of these things don't worry me, but this one does.
I'm semi-responsible for some Juniper gear, thankfully all Junos (BSD) based, but I no longer trust any of it if this is malicious injection vs. a bad review. However, what the hell can I do? I can't audit the code. I trusted Juniper, and now I'm stuck with that trust being burned. Running to any other proprietary network vendor is just as uncertain.
If Junos gets a bulletin, I have a lot of work on my hands very soon, as do a good chunk of service providers. I remember there being rumors of a certain three-letter agency saying they had some type of exploit for the Cisco ASA as well; I wonder if it was something this deep, vs. just a run of the mill RCE vuln.
This is one more reason to use open-source products for actually security-sensitive systems, maintain a good amount of defense in depth, and do a little bit of auditing of the code you're using yourself. More often than not these days, it sure pays to be paranoid.
EDIT: At the same time, this also really makes me respect Juniper more than I have previously. A company that finds this internally, on their own audit, could have patched it silently and said nothing about it to anybody. It probably would have been better for them PR-wise. The honesty is worth me not jumping ship to another (probably compromised) proprietary vendor, but you betcha if I can get away with it, I'll run something open-source and community audited when I can.
> But as I said I do agree with you ideologically and have to hope that as people get a clue the pendulum will swing back to secure decentralized solutions.
As technology progresses, eventually at some point those in power of that panopticon can actually grab the pendulum before it swings back. That's what you really have to be afraid of: if the surveillance programs get enough of a head start on the people recognizing their own government is watching their every move, they can cause enough havoc behind the scenes that whatever the people end up getting mad amount they can give up for PR, and just continue as usual with any and all of the other programs they didn't figure out.
It's debatable where that point is. I don't think we are quite there yet, but I expect we'll get there in our median lifetimes unless the American people do more than privacy slacktivism.
> Given their abundance, it is remarkable that there is no hint of their existence in the records of the Christian kingdoms of the time. In combination with the impractical layout of the tunnels this has engendered the suspicion that the tunnels were used for a non-Christian cult that developed in the 10th century and later disappeared. In that case the slip passages might be a ritual element to slip off diseases and guilts (rebirth).
Forgive me, because I know little about how these types of things are determined, but I'm curious how anthropologists/archaeologists/etc. arrive at these types of conclusions. Is there evidence of a cult that existed around that time that thought this way, or is this just an educated guess based upon society at the time?
> Because if users migrate and stay on Telegram, it could be much harder for Brazilian courts to get records in the future.
Yeah, that's the way that I see it. I don't believe this is the right kind of gambit to be playing. Not only would I expect Telegram to be even more likely than Facebook to tell the judge to shove the subpoena up his arse, he has escalated a war with a company that often is very good at fighting all of its battles on its own terms.
I am now very curious who the subpoena was going after.
John Gilmore's oft quoted in these cases: "The Net interprets censorship as damage and routes around it." When, if ever, will politicians learn this? Will it take a generation that has grown up on the Internet and watched this to make them realize these actions are pretty futile?