Forum: Rails deployment SSL on Rails questions

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Bill W. (Guest)
on 2007-02-28 20:36
(Received via mailing list)
Greetings!

Please forgive the cross post.  This is my first experience with
implementing SSL, so I'm not even sure if this is an application
development or deployment issue.  I hope you'll forgive the "stupid
newbie" questions.

I'm going to install SSL over part of my app and will be using a cert
from Geotrust.  I'm considering two options:  Quick SSL, and Quick SSL
Premium ( http://www.geotrust.com/buy/certificate_compare.asp ).  The
main difference is that QuickSSL has a static seal and the Premium has a
"Dynamic seal stating transaction is secure. Displays real-time date /
timestamp"

1) Does the seal go on all the secure pages?
2) Does the Dynamic seal pose any issues for Rails apps?

I'd really appreciate hearing from anyone with experience with this
stuff.

Thanks,
Bill
Anton A. (Guest)
on 2007-03-01 02:06
(Received via mailing list)
Bill W. said the following on 02/28/2007 01:36 PM:
>
> I'd really appreciate hearing from anyone with experience with this stuff.

Basically its all meaningless.

Go and real the POLICY documents behind them, the equivalent of the EULA
and
liability declarations.

The issue of 'where' is policy.  If you miss out a SSL page they are not
going to come and beat you up or take you to court for non-compliance.

The 'dynamic' seal is no different from any other such chunk of
javascript-enabled dynamic update, like a clock or weather indicator.
its not going to make your site more secure.

What will make you site more secure has little to do with SSL.  Much has
been written on that and advising on it is about 30% of my business.
There
are good books and papers out there; google and amazon are your friends.

SSL has many myths associated with it, and 'security' is one of them.
All it does is encrypt the link.  Even this isn't very good as there are
many appliances sold as tools for corporate gateways that can spoof the
connection in a way that is really a man-in-the-middle attack.

If all you are doing is protecting what's going on over the wire then a
self-signed certificate is adequate.  The Apache tools on my Linux box
has
all the stuff needed.  I did this once, long ago, to try it out but  s
slips
my memory right now.

What companies like Verisign are selling is a form of trustworthiness.
Even
that is a chimera.  Let me explain why.

When you visit a site that purports to be Amazon and carry out a
financial
transaction you want to be sure that it really is Amazon you are dealing
with, as well as securing the electrons over the wire.  But if anyone
can
set up a self-signed cert then what?   So we have 'certificate
authorities'
like Verisign.  The idea is that if the cert comes from Verisign then
you
can trust it.

Why?

Well, Verisign _should_ have verified that the company applying for the
cert
IS who they say there are, all the due diligence about their integrity,
business practices, how they secure their network, their programming
techniques, that they do own the domain and the IP addresses, and so on
and
so on and so on.  All the stuff that I audit for in my "day job'.

But the reality is that they actually sell a whole pile of grades of
certs.
Some of them you just have to apply for and pay the money - the only
thing
they check is that the credit card transaction goes through.

This is not a put-down of Verisign or any other cert authority.  Its
marketing.

Read the licensing agreements.  Unless they are doing a due diligence
check
on you as a business then what you are getting offers no more protection
than a self signed cert.

However if you as a company need the marketing panash of displaying a
known
"badge" on your pages, then that's another matter.

The issue is WHAT ARE YOU TRYING TO ACHIEVE?

The way you've worded your question is open.  If its asking about
technical
superiority, then technically ANY SSL certificate is equivalent to any
other
- even a self signed one.




--
Never look a gift horse in the mouth.
    Saint Jerome, On the Epistle to the Ephesians
Bill W. (Guest)
on 2007-09-26 01:04
(Received via mailing list)
Hi Anton,

I want to start by saying 'thanks.'  I really appreciate the time you
spent
on this excellent post.  It's very helpful to me.

Anton A. wrote:

> Go and real the POLICY documents behind them, the
> equivalent of the EULA and liability declarations.
>
> The issue of 'where' is policy.

Excellent.  That makes that easy.  I'll just do whatever they say I
should
do.

> The 'dynamic' seal is no different from any other such
> chunk of javascript-enabled dynamic update, like a
> clock or weather indicator.

My site already uses a bunch of js; both handcoded and RJS.  From what
you've said I'm guessing it won't pose any new problems if I decide to
go
the Dynamic route.  If there are any technical gotcha's you know of  wrt
Rails / Mongrel / etc., I'd sure appreciate hearing about them.

> If all you are doing is protecting what's going on over the
> wire then a self-signed certificate is adequate.
> <snip>
> However if you as a company need the marketing panash
> of displaying a known "badge" on your pages, then that's
> another matter.

I need both the wire protection and the marketing panash.

> The issue is WHAT ARE YOU TRYING TO ACHIEVE?

Basics of the site are:  Visitor enters or uploads/edits personal health
information at my site, then saves it to their PC.

I need to provide the visitor with a secure link during the time their
personal information is in my site or in transit to my site from their
PC or
in transit from my site to them.  I need to make sure their information
doesn't get cached along the way.  The in-transit issues are the
technical
ones I'm tackling with SSL.  In addition to the technical side, though,
I'm
also trying to give them something recognizable that confirms what I've
told
them I'm doing to protect their information while it's in transit or on
my
site.  So that's where the badge comes in.  Do you know if, from a
marketing
perspective, there's any data on consumer perception of one over the
other?

I delete all their information from my site when they click the button
that
says 'Remove My Info', or if their session goes inactive for 5 minutes.
I
know SSL has nothing to do with that but I'd like to do something
equally as
recognizable as the badge that provides confirmation that their data is
in
fact getting deleted as I say it is.  Any thoughts on where to start
looking
for that would be very much appreciated.

Thank you again for makiing the time to provide such a great reply.  I
really appreciate it.

Best regards,
Bill
Anton A. (Guest)
on 2007-09-26 01:08
(Received via mailing list)
Bill W. said the following on 02/28/2007 03:18 PM:
> Hi Anton,
>
> I want to start by saying 'thanks.'  I really appreciate the time you spent
> on this excellent post.  It's very helpful to me.

I should be charging for this :-)

> Anton A. wrote:
>
>> [big snip]


> I need both the wire protection and the marketing panash.

You need a LOT more, based on what I read from you.

>> The issue is WHAT ARE YOU TRYING TO ACHIEVE?
>
> Basics of the site are:  Visitor enters or uploads/edits personal health
> information at my site, then saves it to their PC.

Most places in the world you are also running into legal constraints as
well as techncial ones.

Speak to a lawyer.  You will need a privacy & compliance notice on your
site
and and an explicit 'release' from your users saying they understand and
accept a whole pile of stuff.  What stuff depends on the country,
province
or state you are in.

SEE A LAYER.

> I need to provide the visitor with a secure link during the time their
> personal information is in my site or in transit to my site from their PC or
> in transit from my site to them.

That's your basics.

> I need to make sure their information
> doesn't get cached along the way.

You can't do that.
You can't control where they come from - they may not be using "their
own"
PC.  They may be accessing from work, from a kiosk, from a library, from
an
internet café or from a rogue wireless connection in an airport waiting
lounge.  See
http://www.intergovworld.com/Pages/Item/Article.as...

You have no control over where they access your site from, any
firewalls,
routers, proxies or anything else along the way.  If one of those
devices is
 something that, for example as part of their employers network
infrastructure or the malicious machinations of the guy running the
rogue
wireless service (or the internet café for that matter) then tough.

THAT is why you need a layer to write your if-but-maybe agreement.

> The in-transit issues are the technical
> ones I'm tackling with SSL.  In addition to the technical side, though, I'm
> also trying to give them something recognizable that confirms what I've told
> them I'm doing to protect their information while it's in transit or on my
> site.  So that's where the badge comes in.  Do you know if, from a marketing
> perspective, there's any data on consumer perception of one over the other?

An immense amount of stuff but I don't keep it to hand.  I'd have to go
through past magazine.  Googling for it would be quicker.  Try some
InfoSec
sites.

> I delete all their information from my site when they click the button that
> says 'Remove My Info', or if their session goes inactive for 5 minutes.  I
> know SSL has nothing to do with that but I'd like to do something equally as
> recognizable as the badge that provides confirmation that their data is in
> fact getting deleted as I say it is.  Any thoughts on where to start looking
> for that would be very much appreciated.

Other than asserting it and having them trust you, I can't think of
anything, and I can't think why they should trust you, unless its some
irrational extension of the the SSL badge.  Rather like the people who
think
  that the newspapers wouldn't publish anything that wasn't true.  And,
yes
there are a lot of people out there who see the Internet like that or
spamming wouldn't be so profitable.


> Thank you again for makiing the time to provide such a great reply.  I
> really appreciate it.

You're welcome.

Now go see a layer.

--
Never forget: The road to Hell is paved with good intentions.
So tread hard on good intentions. -- rjd4
This topic is locked and can not be replied to.