Slashdot Mirror

You know that. I know that. But someone with little or no experience with web browsers probably won't know that.

My point was: a web app can't be treated like "any other networked program" because the clients and protocols have some unique considerations you have to keep in mind.

I've programmed for the web for almost 10 years now, and have always tried to keep a focus on security. I would hesitate to do a project like this myself, because I know there are a lot of ways things can go wrong. So many details to err on. Just look at HTTPS alone.. Is the site vulnerable to the BEAST attack? Are CA's still trustworthy enough? Is your server's SSL configuration actually secure (O hi, yes we accept anon key exchange, go ahead mr MitM)?

So many pitfalls.. Even Raging Paranoia(TM) would just be a good start, nothing more.

Now, look at the question.

new website which would require extremely high levels of security (i.e. I need to be sure that my servers are as 100% rock-solid, unhackable as possible.) [...] I am clueless of what is requires to create a web server that is as secure as, say, a banking account management system.

My advice:
1. Learn HTML, JS and HTTP
2. Read up on "best practices" - understand them
3. Read up on top10 website problems, make sure you fully understand each and every one of them.
4. Read some details about various high-profile website hacks. See how a small, overlooked detail set the whole security tower falling to the ground.
5. Now you're starting to get the basic knowledge required to find who to hire to code this for you. Hire a team to actually code it.

1st: Use this link to verify, takes 1-3 minutes approximately:

https://www.ssllabs.com/ssldb/analyze.html?d=wikimedia.org&s=208.80.152.200

Gets an "A" rating here and yet, it ONLY supports TLS 1.0

(Which means an attack like "BEAST" can "get to it" IF the user is "man-in-the-middled" via the javascript that loads it &/or java pages that exploit it)

NOW, to "double-verify" what's shown above from SSLLabs?

Opera ALSO has developer tools for that too -> View Menu, Developer Tools submenu, Page Security Info

Results - says wikimedia's NOT secure by its standards currently, & has NO security certificate for wikimedia.org...

Lastly, & perhaps most importantly (other 1/2 of the Client-Server equation/interaction here, is the browser itself used):

Opera has TLS 1.1 & 1.2 encryption options (1.1 is enabled by default, 1.2 you must activate) - only "safe(r)" browser I know of that's equipped to THAT level, currently, for certain.

* IN ANY EVENT - I haven't had my coffee yet (going to now in fact though), but I *think* I "hit on" the right pages above, per this article, to do the pertinent tests from reputable/reliable sources &/or tools for the job...

APK

P.S.=> Oh, & yet another thing to "test/look at" is "What's that site running?" by NetCraft

http://uptime.netcraft.com/up/graph?site=wikimedia.org

(Because it can point you to what Server OS & WebServer builds are being used, which tells you if they are PATCHED FOR SECURITY OR NOT, vs. things you can see in exploit-db for example (because all malware makers/hacker-crackers have to do, is stay 1 exploit ahead of ANY sites' patched levels basically to abuse them)).

E.G.-> For Apache (since it applies here to wikimedia.org), for example, you'd want to be SURE it's got builds capable of using a mod_ssl that allows TLS 1.1/1.2 (not just 1.0, because of "BEAST" above mainly) - that's where querying GOOGLE or BING for this:

http://www.google.com/search?sclient=psy-ab&hl=en&site=&source=hp&q=%22Apache%22+and+%22TLS%22&btnG=Search

Helps...

... apk

For JAVA, javascript, ANY plugins, cookies, iframes/frames, etc. as well (so you use them on sites you absolutely NEED to have them active on, otherwise, you can set a GLOBAL POLICY to have them ALL OFF, on ALL SITES, by default).

And, it's as easy to setup for yourself (for not only better online security, but also MORE SPEED as a pleasant side-effect/bonus):

---

1.) Opera's GLOBAL preferences -> Tools menu, Preferences submenu, Advanced, Content, Enable Plugins/Enable Plugins only on demand (as well as cookies, javascript, iframes/frames, & more too) - to make a "GLOBAL DEFAULT POLICY" FOR ALL PAGES to have these things turned off, by default... first!

Then, do a "by site preferences" exception list as you need to for various sites, this way for those things:

2.) Opera's right-click on a website page "By Site Preferences" - this allows you to use any of those things for sites you need them on ONLY (but not by default for all sites).

---

* OPERA ALSO HAS OPTIONAL (not turned on by default, YOU have to make it active) TLS 1.2 encryption for SSL pages too!

APK

P.S.=> In Opera - You can test sites for their TLS/SSL levels too (in the case of Apache specifically, it's mod_ssl, iirc) via this in OPERA also built-in natively as a GUI tool:

Opera's View menu -> Developer Tools submenu -> Page Security Info submenu

& you can "double-verify" that test, via this website also:

https://www.ssllabs.com/ssldb/analyze.html?d=slashdot.org&s=216.34.181.45

... apk

That I already noted here, many times now (in addition to be "javascript immune" on my end):

https://www.ssllabs.com/ssldb/analyze.html?d=slashdot.org&s=216.34.181.45

OR BUILT IN TOOLS IN OPERA 11.51 CAN DO THE SAME:

Opera's View menu -> Developer Tools submenu -> Page Security Info submenu (outlines what type of SSL, TLS, certificates & such that a site offers, by PAGE no less).

APK

P.S.=> Then, if a site "passes muster" on those 2 tools methods (if not triple checking by emailing a webmaster on it) for SSL + TLS check? You also can feel safe that OPERA ALSO HAS BUILT-IN (optional by default) TLS 1.2 LEVEL SSL ENCRYPTION...

Though immunizing yourself via not using javascript @ via Opera "By Site Preferences" exceptions in combination with its GLOBAL POLICIES (set all cookies, iframes, javascript, plugins, etc. OFF, 1st) all stops you from getting "beast infected" @ all, period... apk

Disabling javascript as I do does better, because I can't get infested by BEAST in the 1st place!

APK

P.S.=> For example? Opera allows for GLOBAL policy sets (not using potentially dangerous things like iframes, plugins, javascript, cookies, etc./et al, 1st)...

1.) Tools menu -> Preferences submenu -> Content left-hand-side ribbon item (uncheck them ALL as to javascript, iframes, cookies, & plugins, FIRST - this creates a "global default policy" of ONLY letting those potentially dangerous things run in the 1st place on sites you frequent, or don't frequent & stumble upon/are linked to).

Then, you can set "by site" prefs to run each/any (or all) of them individually BY SITES you choose, is how/why...

AND, again - If you don't use javascript (I avoid things like ecommerce because of it in fact)? You can't be harmed...

2.) Then, for example, to make an EXCEPTION? Say on YouTube (specifically since it regards FLASH)? Right-click on the page itself... the popup menu has an "EDITSITE PREFERENCES" menu item (use it): There is a CONTENT tab (for plugins & more), COOKIES tab, SCRIPT tab (javascript), DISPLAY tab (iframes/frames), & NETWORK tab (for leaving tracking info. of a sort)).

NOW, if you NEED to use javascript for ecommerce, but are worried the site's NOT "SSL safe" vs. BEAST?

You CAN check a site's SSL/TLS level (make sure its 1.1 or 1.2 @ least) via this method in Opera:

Opera's View menu -> Developer Tools submenu -> Page Security Info submenu (outlines what type of SSL, TLS, certificates & such that a site offers, by PAGE no less).

OR, use this site:

https://www.ssllabs.com/ssldb/analyze.html?d=slashdot.org&s=216.34.181.45

(A google query for say, the Apache webserver can also help by showing you which mod_ssl level for OpenSSL is needed for it to be safe server-side too, ala -> http://www.google.com/search?sclient=psy-ab&hl=en&site=&source=hp&q=%22Apache%22+and+%22TLS%22&btnG=Search )

Incidentally, Chromium's latest builds can do pretty much the same via exceptions lists you can make, see screenshot here:

http://it.slashdot.org/comments.pl?sid=2439924&cid=37481432

... apk

Care to disagree with that too? Good luck - you'd need it: Face it boy: You don't have the intellect to get the best of me, on anything in computing (which is why you're an unknown "ne'er-do-well").

"So your browser connected to the server itself and checked specifically for the supported protocol versions, just like I said. Did it really take three replies to agree with me?" - by Qzukk (229616) on Sunday September 25, @08:25AM (#37507338)

I pointed out the built into Opera method & the other tool posted by Lennie does it also:

https://www.ssllabs.com/ssldb/analyze.html?d=slashdot.org&s=216.34.181.45

As do my other "detective methods", but... the POINT OF THE ARTICLE/TOPIC is BROWSER-SIDE STUFF dolt!

Thus? Opera, a webbrowser, has TLS 1.1/1.2 built into it, as well as "BY SITE PREFERENCES/EXCEPTIONS" for javascript, iframes/frames, cookies, plugins, etc. (Face it - which is ENOUGH TO IMMUNIZE A USER vs. THE "BEAST" ATTACK, period!).

APK

P.S.=> And, you KNOW IT, and thus, "U FAIL"... period!

... apk

Opera's View menu -> Developer Tools submenu -> Page Security Info submenu (outlines what type of SSL, TLS, certificates & such that a site offers, by PAGE no less).

* Opera 11.51 again "FTW"...

APK

P.S.=>

"The only way to know what version of SSL/TLS is supported is to connect and ask for decreasing versions until one is accepted." -by Qzukk (229616) on Thursday September 22, @12:39PM (#37481460)

Actually, I do know because of Opera... & THERE IS (again) A "GUI TOOL" FOR IT, BUILT INTO OPERA, NATIVELY... see above, OR the tool Lennie noted here:

https://www.ssllabs.com/ssldb/analyze.html?d=slashdot.org&s=216.34.181.45

Take your pick (but again, me? I cannot, absolutely CANNOT be "hit" by this "BEAST" attack, or any delivered via javascript (like so many are), because again?? I DO NOT USE IT, period (it's not trustworthy, especially nowadays)...

... apk

1.) So you use NETCRAFT's "What's that site running" here:

  http://uptime.netcraft.com/up/graph?site=slashdot.org

To determine what webserver a site runs (what build level), first.

2.) Then, query a search engine for what webservers have TLS 1.2 in them, ala:

http://www.google.com/search?sclient=psy-ab&hl=en&site=&source=hp&q=%22Apache%22+and+%22TLS+1.2%22&btnG=Search

3.) & if NEED be, write the website on what "mod_ssl" level they use currently & warn them to update to the one that has TLS 1.2...

* Easy as pie, & even EASIER than step #3, is to just use this:

https://www.ssllabs.com/ssldb/analyze.html?d=slashdot.org&s=216.34.181.45

That last tool I have to thank someone named "Lennie" here on in an exchange he & I had today (much more direct on determining SSL TLS level used on a site than my "detective methods")...

APK

P.S.=> Funniest part is, I'll never EVER get hit by "BEAST", because I don't use javascript here "indiscriminately" (hell, I never do, I don't even do "ecommerce" because I know the security-downsides of Javascript is why)... but, time to "take you apart" in your quotes now (the FUN part):

"That won't work. The way TLS works is the client says 'hey I have 1.2" and the vast majority of servers reply, "cool, but I only do 1.0 so do that instead" and the client obliges." - by Anonymous Coward on Thursday September 22, @10:25AM (#37479622)

See the above, & "tell us another one", ok? IF you don't have javascript active (especially "everywhere + indiscriminately" though? Like myself, you CANNOT BE HIT BY IT, period!).

Care to debate that, you ac troll??

---

"Old servers reply with "error there is nothing other than 1.0" so that's why the default is 1.0 on clients" - by Anonymous Coward on Thursday September 22, @10:25AM (#37479622)

So, see the above - I provide tools to check "server-side" also for TLS/SSL levels, what builds of a webserver have it, as well as what a server runs... simple!

(Guess you didn't KNOW that, eh, troll? LOL...)

First of all, I am ONLY extolling the fact that Opera already has a few "built in/native" mechanisms for combatting this (perhaps the best is its "by site" prefs & not using potentially dangerous things like iframes, plugins, javascript, cookies etc./et al, rather than its TLS 1.2 option it already has).

---

"Also everybody APK is a troll" - by Anonymous Coward on Thursday September 22, @10:25AM (#37479622)

Ahem: EXCUSE ME, but aren't YOU THE ONE TROLLING VIA AC REPLIES + ADHOMINEM ILLOGICAL LIBELLING ATTACKS NOW?

Yes, you are... pot calling the kettle black!

---

"I did not want to feed him, but felt it was important to let others know not to follow his 'legit' advice." - by Anonymous Coward on Thursday September 22, @10:25AM (#37479622)

What's not "legit" about what I wrote last round in Opera being able to defend a user, BROWSER SIDE (the topic here mainly) vs. SSL type attacks like "BEAST"?

(Now, I know this AC troll will run from this, or go off topic & attempt more illogical adhominem attacks, but I always have fun with him, making him look more ignorant than he already is, everytime)...

... apk

See subject-line above & thank you for the thanks!

APK

P.S.=> I had to thank someone for supplying me a direct tool here too, in Lennie's replies in fact, for an online analysis tool he provided myself (& others) here in fact - NOT A "WASTED DAY" if you learn a new thing I figure!

His tool (vs. my 2-3 step detective work methods), saves a few seconds of work actually!

(Yes, I can do that with a couple more steps for the most part, via:

NETCRAFT'S "What's that site running" -> http://uptime.netcraft.com/up/graph?site=slashdot.org

&

A simple GOOGLE or BING query -> http://www.google.com/search?sclient=psy-ab&hl=en&site=&source=hp&q=%22Apache%22+and+%22TLS+1.2%22&btnG=Search on webserver(s) that have TLS 1.2 abilities)...

So... you MAY wish to look into Lennie & my "exchange/debate"!

He illustrated good tools are there for you to use also that combine with Opera's TLS 1.2, & "By Site Prefs" abilities (unique to Opera in fact afaik & native to it) to secure yourself vs. this threat, & identify (especially for your FAV sites you frequent most) which sites have TLS 1.2 abilities in their webservers (IF NEED BE? Well - You can email the folks here on a site too asking on their TLS level if needed, or use Lennie's tool here -> https://www.ssllabs.com/ssldb/analyze.html?d=slashdot.org&s=216.34.181.45 )...apk

That does not help, it does not show what version of HTTPS it supports.

The way to check HTTPS versions/protocol features and so on is at:

https://www.ssllabs.com/ssldb/analyze.html?d=slashdot.org&s=216.34.181.45

This is what it says on the page:
TLS 1.2 No
TLS 1.1 No

But it obviously still does not tell you if _you_ are connected to a server with supports it and if client and server are using it right now.

Trust me, most don't support it.

The best and most simple way to make sure you are safe is:
- close the browser (all existing HTTPS-connections are thus closed)
- open the browser
- only open a tab/window to the HTTPS-site and don't forget to type https:/// infront of it
- and use that
- when you are done
- logout on the site
- close the browser

Works fine with SSL/3.0 or TLS/1.0

Because what the attacker needs to do is through some other channel inject plain-text into the stream you are using to connect to the HTTPS-site.

The man-in-the-middle attacker does this by modifying a page loaded over HTTP that you loaded on a different page.

If all you have open is the one site, they can not do that.

At least the SSL they have is configured properly https://www.ssllabs.com/ssldb/analyze.html?d=twitter.com

Unlike some banks...

I mentioned Qualys' SSL Labs nice test utility in another comment.

The fix is to ask your vendor for a patch for CVE-2009-3555 which implements RFC 5746 Transport Layer Security (TLS) Renegotiation Indication Extension. Responsible vendors will have implemented support for RFC 5746 by now so you may already be patched.

I like Qualys' SSL Labs

Obviously such attacks are possible because of the application security, renegotiation just makes it easier. BTW, here is a tool to check if your server is vulnerable to renegotiation attacks: https://www.ssllabs.com/ssldb/

BTW, clients (e.g. browsers) are pretty save - there is NO need to panic!!

Those of you in charge of maintaining SSL servers, you might be interested to know that there's a new online assessment service.

Free, no strings attached (not even ads).

https://www.ssllabs.com/ssldb/

Cheers, Ivan

Well, the problem is that you can't get connection encryption (confidentiality) without authentication. This is because, unless you authenticate with the server you wish to talk to, you can _never_ tell if there's someone in the middle snooping all your traffic (and possibly modifying it as well). It's the infamous man-in-the-middle (MITM) attack, and it's trivial to pull off if the attacker is in the right spot. The world is heading toward two classes of certificates anyway. The price for normal certificates (for which you only need to demonstrate that you control the domain name in question) is going to continue to go down. I hope that one day you'd get your certificate for free with a domain name purchase. Extended Validation (EV) certificates, where certificate authorities actually do some work to validate an organisation behind a certificate, are going to be what you call "full-mode" certificates. Speaking of SSL, just last week I launched a free online service where you can test the configuration of any SSL web site: https://www.ssllabs.com/ssldb/