Re: HTTPS Only 3.1 (Detailed Analysis, Browser Security, Open Source, Python)
> On Thu, 24 Mar 2016, Kevin Chadwick wrote: > > BTW, only allowing Javascript to come from the primary domain over SSL > > would be a far saner idea, but lets see you get that past Google, > > facebook and all the other tracking sites? > > It's possible with content security policy[1][2], but completely > optional and up to the webmaster (custom header sent by the server). > Google etc are actually pushing for it. > > [1]: https://en.wikipedia.org/wiki/Content_Security_Policy > [2]: https://developer.mozilla.org/en-US/docs/Web/Security/CSP Please, you think that says anything about Google, it doesn't even say anything about a few Google developers? Google generally works in teams of four by the way apparently. Yes I have that enabled on my sites as there is NO javascript at all but that is next to useless as my sites aren't problem sites. The noscript extension for firefox appears to increase firefox's startup use of memory by more than the xombrero browser uses on startup! Here's a question or two. Why can you not clear any content on browser shutdown on chrome but can in comodos version called chromodo. Why are the chrome javascript controls next to useless and hitting enable has no effect on video sites that try to ensure adverts have been run? I could throw in why google are adverse to firewalls but that would open up more trolling. I have nothing against Google btw but some of their software design decisions are as bad as Apples engineering. Anyway, non of this has anything to do with OpenBSD as I doubt libressl and it's CA ability would be the chosen solution to any OpenBSD security problems when there is OpenSSH available and many of the developers meet regularly enough. So I assume the developers would agree that it would be good if https everywhere nonsense wasn't brought up on this list again please. -- KISSIS - Keep It Simple So It's Securable
Re: HTTPS Only 3.1 (Detailed Analysis, Browser Security, Open Source, Python)
On Thu, 24 Mar 2016, Kevin Chadwick wrote: > BTW, only allowing Javascript to come from the primary domain over SSL > would be a far saner idea, but lets see you get that past Google, > facebook and all the other tracking sites? It's possible with content security policy[1][2], but completely optional and up to the webmaster (custom header sent by the server). Google etc are actually pushing for it. [1]: https://en.wikipedia.org/wiki/Content_Security_Policy [2]: https://developer.mozilla.org/en-US/docs/Web/Security/CSP
Re: HTTPS Only 3.1 (Detailed Analysis, Browser Security, Open Source, Python)
> Now, let's look at threats: > 1. Man in the middle - it's fixed. > 2. Phishing always requires the browser to load attacker's website, so it's > permanently dead here. > 3. Drive-by Download - dead(if applied strictly, unable to download the > executable) > 4. Clickjacking - dead(attacker's web page is unreachable) > 5. Address Spoofing - dead too(just unable to load the fake content) > 6. XSS - almost dead(for attacker, the XSS vulnerability has to be GET, > because POST requires attacker's HTML) > 7. CSRF - almost dead(for attacker, the CSRF vulnerability has to be GET, and > modern web applications simply don't do > important things in GET, because it can be bookmarked etc, too dangerous) BTW, only allowing Javascript to come from the primary domain over SSL would be a far saner idea, but lets see you get that past Google, facebook and all the other tracking sites? -- KISSIS - Keep It Simple So It's Securable
Re: HTTPS Only 3.1 (Detailed Analysis, Browser Security, Open Source, Python)
> To secure browser which is very fragile, the approach of HTTPS Only 3.1 is > exceptionally simple: Please help make widespread browsers "Simple" firefox now takes > 200M mem without any tabs open and chrome is > 70M to download. Xombrero uses 30-45 M of mem > 1. Only HTTPS URLs(no other protocols) > 2. Whitelist of domains(anything outside of whitelist is blocked) > > Now, let's look at threats: > 1. Man in the middle - it's fixed. > 2. Phishing always requires the browser to load attacker's website, so it's > permanently dead here. > 3. Drive-by Download - dead(if applied strictly, unable to download the > executable) > 4. Clickjacking - dead(attacker's web page is unreachable) > 5. Address Spoofing - dead too(just unable to load the fake content) > 6. XSS - almost dead(for attacker, the XSS vulnerability has to be GET, > because POST requires attacker's HTML) > 7. CSRF - almost dead(for attacker, the CSRF vulnerability has to be GET, and > modern web applications simply don't do > important things in GET, because it can be bookmarked etc, too dangerous) > So you want to avoid attacks caused by people who don't know what they are doing with making DDOS more effective and the most widespread attack that affects everyone?? > URLs: > Project Home Page: https://www.httpsonly.net/View Source Code: > https://www.httpsonly.net/source/ > Kind Regards, > > I'm not the owner of this software, just wanted to share the idea. Have a > nice day! I assume you are a Troll. Please don't be a Troll, Thankyou. -- KISSIS - Keep It Simple So It's Securable
HTTPS Only 3.1 (Detailed Analysis, Browser Security, Open Source, Python)
Hello all! http://seclists.org/fulldisclosure/2016/Mar/77 HTTPS Only 3.1 (Detailed Analysis, Browser Security, Open Source, Python) From: David Leo Date: Wed, 23 Mar 2016 01:58:43 -0700 To secure browser which is very fragile, the approach of HTTPS Only 3.1 is exceptionally simple: 1. Only HTTPS URLs(no other protocols) 2. Whitelist of domains(anything outside of whitelist is blocked) Now, let's look at threats: 1. Man in the middle - it's fixed. 2. Phishing always requires the browser to load attacker's website, so it's permanently dead here. 3. Drive-by Download - dead(if applied strictly, unable to download the executable) 4. Clickjacking - dead(attacker's web page is unreachable) 5. Address Spoofing - dead too(just unable to load the fake content) 6. XSS - almost dead(for attacker, the XSS vulnerability has to be GET, because POST requires attacker's HTML) 7. CSRF - almost dead(for attacker, the CSRF vulnerability has to be GET, and modern web applications simply don't do important things in GET, because it can be bookmarked etc, too dangerous) URLs: Project Home Page: https://www.httpsonly.net/View Source Code: https://www.httpsonly.net/source/ Kind Regards, I'm not the owner of this software, just wanted to share the idea. Have a nice day!
