Critical bug in your website!

[Kirtikumar Anandrao Ramchandani]

any update sir?

On Thu, Apr 12, 2018 at 6:19 PM, Kirtikumar Anandrao Ramchandani <
kirtiar15502 at gmail.com> wrote:

> Assigned to:- piggin
> Assigned by:- Kirtikumar Anandrao Ramchandani
> Assigned on:- 12/04/2018
> Bug overview:- HSTS preload missing!!
> URL vulnerability present in:- http://pidgin.im/
> Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
>
> This Preload is missing!!
>
> HSTS Preloading
> HSTS Preloading and the steps we can make to move towards a safer web.
>
> What does this mean?
> The first time a browser attempts to initiate a connection with a website,
> it will default to standard HTTP; regardless of whether an HSTS header is
> set.
>
> This is because it has never visited it before and so simply does not know
> of the Http Strict Transport Security response (known as the TOFU security
> model). This means that the first request to a secure site is vulnerable to
> a MITM and therefore could still be intercepted.
>
> Since my site is enrolled on the strict list, it knows that the first time
> a user tries to connect to my website (and every other time, for that
> matter) - it should default and only ever use HTTPS.
>
> Publication
> Pros/Cons In this section I will discuss the pros and cons of being
> preloaded, with that also highlighting the reasons I chose to enroll.
>
> Pros
> HTTPS enforced both server and client-side.
> This is good because in the case that the server protocol is ever
> compromised, the client-side browser will refuse to initiate the connection
> and thus prevent further leakage.
>
> Google are starting to use this as a SEO ranking metric.
> Enforce HTTPS, get an higher ranking. Enforce it at the client side, get
> an even higher ranking.
>
> Cons
> You must be able to support HTTPS for the long term.
> You must be committed to the idea of a web with no HTTP. If for what ever
> reason you cease support for HTTPS in the future, your users will not be
> able to connect to your site - even if you remove the server-side HSTS
> header. This is because the strict list is hard-coded into the end user's
> browser.
>
> Further more, it is a difficult process to be removed from the list.
>
> Conclusion
> I believe that if we want to move to a more secure web, we must enforce
> greater security. And even consider edge cases, such as the user's first
> visit.
>
> Thus, I would much rather a user not be able to connect to my site at all
> than the contents be transmitted in plain text. It is for this reason, this
> site is strictly enforced as being strict-https on most modern major
> browsers (Chrome, Firefox, Opera, Safari, +).
>
> Note: This is NOT a replacement for the server-side enforcement of HSTS.
> You need both. Why? Your users may use less common web browsers, those that
> won't have a hard-coded HSTS list.
>
> You should also recommend your users use a modern browser for this
> strategy to be effective. Or where not possible, make use of a browser add
> on such as HTTPS Everywhere.
>
> Best Regards
> Kirti
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/cgi-bin/mailman/private/security/attachments/20180426/bd3e3ed2/attachment-0001.html>