https implementation

[Mázsa Péter]

clicking on the lock (cf. attachment) you will see this message:
"Your connection to www.clipperz.com is encrypted with 256-bit
encryption. However, this page includes other resources which are not
secure. These resources can be viewed by others while in transit, and
can be modified by an attacker to change the look of the page."

cf. http://www.troyhunt.com/2013/05/why-i-am-worlds-greatest-lover-and.html

+ FYI:

https://www.ssllabs.com/ssltest/analyze.html?d=clipperz.com

P.

[giulio...@gmail.com]

Hello Péter,

the warning is probably be due to direct login favicons being loaded with 'http' instead of 'https'.

With /gamma you have the option to customize the favicon of each direct login, but I am not sure this is a worth effort.

Clipperz application is all included in the main 'index.html' page, and so it is sent to the browser over https, so can't be tampered on its way across the net. Data are requested using a relative path (../json), so they will use the same protocol them main application was loaded with.

I understand that it is not nice to have a security waring on the page you use to manage your secretes, but there should be any real thread related to this specific note.

Best regards,

Giulio Cesare

P.

--
You received this message because you are subscribed to the Google Groups "Clipperz" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clipperz+u...@googlegroups.com.
To post to this group, send email to clip...@googlegroups.com.
Visit this group at http://groups.google.com/group/clipperz?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.

[Mázsa Péter]

Dear Cesare,

first of all, thank you for the opportunity to use your wonderful open
source software. I write all this in order to make it more secure - or
let it reveal its real security:)

At first I thought as well that the favicons are the problem, but if I
click on the lock and change permissions to "Images: always block on
this site" and reload clipperz, the page still "includes other
resources which are not secure". (And you can allow images and get a
green lock at the same time, check your gmail for example).
If you block javascript, you get your green lock but then, of course,
you can't use clipperz.
So it seems to me that the problem can not be with the favicons.
However what you wrote is very comforting:

> Clipperz application is all included in the main 'index.html' page, and so
> it is sent to the browser over https, so can't be tampered on its way across
> the net. Data are requested using a relative path (../json), so they will
> use the same protocol them main application was loaded with.

maybe there is a way we can reveal this inherent security as a green
lock as well?

The other topic is the ssl overall rating "C":
https://www.ssllabs.com/ssltest/analyze.html?d=clipperz.com
I don't think so the 40bit cipher suites option is a serious problem
in practice: Chrome enforces the most secure suite
(TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 1024 bits (p: 128, g: 1,
Ys: 128) 256) by default. But what about these details (attached):
"BEAST attack Vulnerable INSECURE (more info)
RC4 Yes PROBLEMATIC (more info)
Session resumption No (IDs empty)"
This may be not a trivial problem: https://www.site5.com (a Big
Company https://www.site5.com/about/the-site5-team ) converted their
rating F to the present A in 9 days when I drew their attention to the
problems last month.

Yours:
P.

[giulio...@gmail.com]

Hello Péter,

your observations are all very interesting. At the moment I am very busy trying to complete some tasks with a very hard deadline (I have a slot to talk on next week Italian JSDay, and I still have to prepare it).

But I will get back to the SSL configuration after May 20th, and try to address all of your concerns.

I may get back to you for asking more questions once I start working on it.

Thanks for the very useful feedback!

Best regards,

Giulio Cesare

[Justin_08]

I believe that this could help everyone.  If not for this case in particular than certainly in your other day to day banking or any other secure log-in's.  It is the new Fingerprints project / tool that Steve has built (is still working on) over at the Gibson Research Center https://www.grc.com/fingerprints

It allows you to compare the security certificates AUTHENTIC fingerprint from any https (SSL/TLS) capable public connection, to the one that is displayed by your browser.  If they differ you know that there is a middle man, not necessarily a security breach or unsecured connection, but at least a middle man.  I believe that even some AV programs like Kaspersky and one or two others intercept the actual certificate first for their users and then the one in your browser will not match.  Also corporations, schools and the like are now apparently intercepting these https connections so as to "keep an eye" on what you are browsing I guess.  So again a security key that didn't match wouldn't necessarily match would not completely guarantee a breech, but could rather point to a "valid" interception. 

I am somewhat new to all of this so I apologize if how I explained this tool is not 100% accurate, but I thought it was great when I found out about it.  His page explains it far better than I ever could.

Thanks

[giulio...@gmail.com]

Thanks Justin for the pointer.

Clipperz security model is still based on the browser being able to verify that the code it receives from the server is what it is expecting, regardless of the actual security of the channel.

But has we don't have a solid solution for this problem yet, we have to keep everything else in perfect order.

Thanks again for the support.

Best regards,

Giulio Cesare