Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: Security of Delphi remoting frameworks



Permlink Replies: 128 - Last Post: Mar 2, 2015 2:28 PM Last Post By: Bruce McGee
Luigi Sandon

Posts: 353
Registered: 10/15/99
Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 13, 2014 2:22 PM
Someone asked this thread so let's start.

Both Datasnap (unless your rely on the old DCOM version, or rely on a web server - which may mean more expensive licensing) and AppTethering lack proper security features - from proper encryption of transmitted data, to proper authentication/authorization techniques. (for my analysis of Datasnap see http://www.sandon.it/?q=node/57, written in 2010 but still actual because little changed since then),

Delphi still supports web services, but the latest (but not recent...) standards like WS Security were AFAIK never implemented.

Would you rely on them to transmit your customers' sensitive data? Could an expensive development tool deliver so little today from a security point of view, especially now data breaches can be very costly both in monetary and reputation terms?

Why Delphi doesn't offer a good cryptographic library, preferably wrapping CryptoAPI on Windows (because this way fixes and updates are automatically delivered, nor complex alorithms need to be reimplemented from scratch) and OpenSSL or the like on other systems? And why then don't build on it proper security into its frameworks?

Real security is no longer optional. Systems becomes more and more interconnected, often remoted, and "gateways" are more and more difficult to control due to the mobile devices and wireless network available, often outside your control but where your customer data will transit.

Real end-to-end security is a first class requirement today. Could Delphi lag behind, and offer too little, especially at its premium price against competition? Should Embarcadero assign more resources to ensure Delphi applications can stand a real scrutiny from a security perspective? Do you feel you need them, or do you believe you can do without? Or do you just use third party frameworks, and Delphi should just dump its ones and save resources to develop something else?
Eli M

Posts: 1,346
Registered: 11/9/13
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 13, 2014 3:33 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Let me preface this by saying I would pretty much never use DataSnap because I prefer server side scripting solutions. I also just use pro+mobile.

However, it appears that DataSnap supports HTTPS (SSL). SSL is industry standard. That is good enough security for me and what I use with a PHP/ASP.NET server side.

You also mention that DataSnap uses JSON. In my view that is also a wise choice. When I roll my own client<->server systems I also use XML or JSON responses from PHP/ASP.NET. I would advocate against a binary protocol unless it was already an industry standard. HTTP also supports gzip compression which is industry standard and reduces the inefficiencies of using a text transport format.

Bottom line is DateSnap appears to support industry standard HTTPS, GZIP, and JSON which would be my requirements for using it to avoid vendor lock in and are actually what I use in my enterprise deployments with PHP and ASP.NET on the server side. Usually my client of choice is a web browser but lately it is also TRESTClient.
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 14, 2014 12:55 AM   in response to: Eli M in response to: Eli M
However, it appears that DataSnap supports HTTPS (SSL). SSL is industry standard. That is good enough security for me and what I use with a PHP/ASP.NET server side.

It forces you to use a web server. There are situation when this is not an option. Also, HTTP is inherently an unidirectional protocol (that's why the ugly WebSocket protocol, AKA TCP over HTTP, was created). You have a client calling a server. The server can't call the client. Callbacks needs to use hacks like leaving an HTTP request pending.

Also, HTTPS relies on a PKI infrastructure and requires certificate management. And to identify client, you also need client certificates. In an AD domain you can use it to deliver certificates and manage them, without, it's a manual management. A self-signed certificate is fake security - you'd need one clients could trust really.

However, SSL is not in any way tied to HTTP. It works perfectly on TCP directly. Sure, you can't rely on someone else webserver to implement it for you.

You also mention that DataSnap uses JSON. In my view that is also a wise choice.

Sometimes is is, sometimes it is not. JSON, like all the data exchange protocols that use a string format, is heavy and verbose. Just a little less than XML, but still heavy and verbose when you need to move a lot of binary data.

If for some kind of applications, i.e. web/mobile to server communication could be Ok, Datasnap aims to be a more comprehensive solution - not just one to write "web application" (is so, Embarcadero should rebadge it).

In a fast LAN endpoints may wish to quickly transfer large data while both using Datasnap. Being forced to transform data back and from an intermediate character based format looks very silly to me. I understand someone believes the string is the ultimate format for every kind of data, but I'm old school, and when I transfer binary data, I prefer to transfer them in their native format, especially when both endpoints know it and don't need any conversion.
Even the designer of HTTP where not so stupid to make it transfer textual data only - HTTP can transfer pure binary data without requiring any special encoding.

Bottom line is DateSnap appears to support industry standard HTTPS, GZIP, and JSON which would be my requirements

My requirements are instead to use pure TCP/IP as the transport layer, without the webserver and HTTP overhead. Also I need true bidirectional capabilities for server-to-server communication. Mine are not "web applications".
Kim Madsen

Posts: 362
Registered: 12/13/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 14, 2014 7:54 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Den 10/14/2014 09:57, Luigi Sandon skrev:
However, it appears that DataSnap supports HTTPS (SSL). SSL is industry standard. That is good enough security for me and what I use with a PHP/ASP.NET server side.

It forces you to use a web server. There are situation when this is not an option. Also, HTTP is inherently an unidirectional protocol (that's why the ugly WebSocket protocol, AKA TCP over HTTP, was created). You have a client calling a server. The server can't call the client. Callbacks needs to use hacks like leaving an HTTP request pending.

Also, HTTPS relies on a PKI infrastructure and requires certificate management. And to identify client, you also need client certificates. In an AD domain you can use it to deliver certificates and manage them, without, it's a manual management. A self-signed certificate is fake security - you'd need one clients could trust really.

However, SSL is not in any way tied to HTTP. It works perfectly on TCP directly. Sure, you can't rely on someone else webserver to implement it for you.

You also mention that DataSnap uses JSON. In my view that is also a wise choice.

Sometimes is is, sometimes it is not. JSON, like all the data exchange protocols that use a string format, is heavy and verbose. Just a little less than XML, but still heavy and verbose when you need to move a lot of binary data.

If for some kind of applications, i.e. web/mobile to server communication could be Ok, Datasnap aims to be a more comprehensive solution - not just one to write "web application" (is so, Embarcadero should rebadge it).

In a fast LAN endpoints may wish to quickly transfer large data while both using Datasnap. Being forced to transform data back and from an intermediate character based format looks very silly to me. I understand someone believes the string is the ultimate format for every kind of data, but I'm old school, and when I transfer binary data, I prefer to transfer them in their native format, especially when both endpoints know it and don't need any conversion.
Even the designer of HTTP where not so stupid to make it transfer textual data only - HTTP can transfer pure binary data without requiring any special encoding.

Bottom line is DateSnap appears to support industry standard HTTPS, GZIP, and JSON which would be my requirements

My requirements are instead to use pure TCP/IP as the transport layer, without the webserver and HTTP overhead. Also I need true bidirectional capabilities for server-to-server communication. Mine are not "web applications".

Why dont you look at kbmMW ;) supports it all and more.

best regards
Kim Madsen
C4D
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 14, 2014 8:40 AM   in response to: Kim Madsen in response to: Kim Madsen
Why dont you look at kbmMW ;) supports it all and more.

I know there are alternatives. This thread is not abou them - and some people may be tired to pay for Delphi features that can't be used...
Kim Madsen

Posts: 362
Registered: 12/13/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 14, 2014 9:14 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Den 10/14/2014 17:40, Luigi Sandon skrev:
Why dont you look at kbmMW ;) supports it all and more.

I know there are alternatives. This thread is not abou them - and some people may be tired to pay for Delphi features that can't be used...

Fair enough.

best regards
Kim Madsen
C4D
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 14, 2014 11:17 AM   in response to: Kim Madsen in response to: Kim Madsen
Fair enough.

Anyway I guess it could be interesting a comparative test among remoting framework from a security point of view also, not only performance/ease of use/etc.
Eli M

Posts: 1,346
Registered: 11/9/13
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 14, 2014 1:21 PM   in response to: Luigi Sandon in response to: Luigi Sandon
It sounds like the HTTPS implementation of DataSnap for general business applications in IIS/Apache Windows deployments on new and existing servers for web services is decent enough. Embarcadero is moving more in the REST service direction as well with the EMS offering in XE7.

Has proxy support been exposed in Datasnap? I know Indy has it and I use it in TRESTClient and TIdHTTP.

It also sounds like the TCP/IP implementation of DataSnap is in need of improvements (which I know you have been advocating for many years).

Does the implementation of filters still have a performance issue?

Would SSH tunneling solve the TCP/IP security issue?

Is there an industry standard binary protocol that could be implemented? I looked at some other middle ware implementations and they appeared to be using their own custom binary formats.

The XMPP protocol is used for IM, video, VOIP, file transfers, etc. It is XML based and for in band binary transfers data has to be base64 encoded which doesn't solve the TCP/IP binary issue. However, binary data transfers can be accomplished out of band with in band message coordination (which is what I would do with HTTPS Datasnap as well). SASL and TLS are a core part of the XMPP specification. XMPP also has a tunneling over HTTP feature in the protocol.

Are most businesses going to want the TCP/IP support (the bi-directional communication) or is the HTTPS support going to fit most uses of Datasnap?

Edit:

IP*Works includes SSH components which would secure the Datasnap TCP/IP connection:

TiphSSHTunnel
TiphSSHReverseTunnel
TiphSSHDaemon
TiphSSHClient

http://www.nsoftware.com/kb/help/IHD9-A/SSHTunnel.rst

Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 15, 2014 6:40 PM   in response to: Eli M in response to: Eli M
Eli M wrote:

Has proxy support been exposed in Datasnap? I know Indy has it and I
use it in TRESTClient and TIdHTTP.

Apparently, yes.

http://qc.embarcadero.com/wc/qcmain.aspx?d=85467

--
Regards,
Bruce McGee
Glooscap Software
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 15, 2014 7:02 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

However, it appears that DataSnap supports HTTPS (SSL). SSL is
industry standard. That is good enough security for me and what I
use with a PHP/ASP.NET server side.

It forces you to use a web server. There are situation when this is
not an option. Also, HTTP is inherently an unidirectional protocol
(that's why the ugly WebSocket protocol, AKA TCP over HTTP, was
created). You have a client calling a server. The server can't call
the client. Callbacks needs to use hacks like leaving an HTTP request
pending.

You can now (since XE2) create a stand alone server with HTTPS support.
No web server required.

Also, HTTPS relies on a PKI infrastructure and requires certificate
management. And to identify client, you also need client
certificates. In an AD domain you can use it to deliver certificates
and manage them, without, it's a manual management. A self-signed
certificate is fake security - you'd need one clients could trust
really.

Self signed certificates obviously can't be used to verify the identity
of the server, but are they really "fake" security? Can't these be used
for encryption and even verification of the server certificate to avoid
man-in-the-middle attacks (just learned about this)?

However, SSL is not in any way tied to HTTP. It works perfectly on
TCP directly. Sure, you can't rely on someone else webserver to
implement it for you.

Now that's interesting. It seems like something I should have known.

http://stackoverflow.com/questions/11844630/delphi-ssl-tcp-communication-with-indy-components

Doesn't seem to be exposed in DataSnap for TCP/IP connections, though.

You also mention that DataSnap uses JSON. In my view that is also a
wise choice.

Sometimes is is, sometimes it is not. JSON, like all the data
exchange protocols that use a string format, is heavy and verbose.
Just a little less than XML, but still heavy and verbose when you
need to move a lot of binary data.

JSON turns out to be a lot less heavy than XML, and easier (and faster)
for other environments to consume.

Which makes my life easier if I want to call the application server
from JavaScript, for example.

I stream binary data from the server (things like PDF documents). I
didn't think they were translated to and from JSON, but I should
probably find out, though.

My requirements are instead to use pure TCP/IP as the transport
layer, without the webserver and HTTP overhead. Also I need true
bidirectional capabilities for server-to-server communication. Mine
are not "web applications".

I don't use dedicated connections as much as I used to.

How do you define "web applications"?

I definitely use REST servers to serve up content for web browsers, but
in most cases, it's just quick, stateless access to an application
server from an arbitrary client.

--
Regards,
Bruce McGee
Glooscap Software
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 5:22 AM   in response to: Bruce McGee in response to: Bruce McGee
You can now (since XE2) create a stand alone server with HTTPS support.
No web server required.

It could be even less secure than using a real web server :) Someone ever verified how sound and secure Indy HTTP server is? And, as you discovered, there's very little need of using HTTP transport when TCP/IP works as well (and TCP/IP, unlike HTTP, is fully bidirectional).

Self signed certificates obviously can't be used to verify the identity
of the server, but are they really "fake" security? Can't these be used
for encryption and even verification of the server certificate to avoid
man-in-the-middle attacks (just learned about this)?

Because you can't verify a self-signed certificate, it's easy to create your own and play a MTM attack with it. A client has no way to detect if that is the right certificate or not.

A PKI system relies on CAs to work, it's its weak point. Without a proper certificate chain validated by a trusted CA, you get encryption, but not real authentication, so you can use MTM.

Again, it could work in some depolyment, but you need to be very careful. For example, if you can, it's better to transfer a CA in some secure way, and then generate server (and clien) certificate using that CA. This way an attacker can't fake a certificate unless he obtains a copy of the CA that generated it. Of course you need to deploy the CA, etc. etc.

If you're in a domain, or in any network where Kerberos is used, for example, you have already a a sound and fully working authentication/authorization infrastructure in place, which doens't rely on PKI. The downside it could only work in a LAN or through a VPN, but it can allow for process-level security - transparently.

Now that's interesting. It seems like something I should have known.
http://stackoverflow.com/questions/11844630/delphi-ssl-tcp-communication-with-indy-components
Doesn't seem to be exposed in DataSnap for TCP/IP connections, though.

Yes - it's one of the thing I asked to implement. At least it will remove web servers and HTTP from the equation.

How do you define "web applications"?

I could define them as mostly client-server stateless applications using HTTP as the transport and open to a large number of clients.

in most cases, it's just quick, stateless access to an application
server from an arbitrary client.

While some application could work better with a stateful approach. Stateless is very good to support a lot of client that make request that doesn't need a state remembered across them (or can re-send the required state each time). Other applications, maybe with a limited number of connection, may need and work better using longer connections with state maintained across calls.

For example, with a stateless client, your database transactions may be forced to last as long as a single request. Usually, it could be a good thing - sometimes, you may need longer transactions across more calls. That depends on the scenario you have to implement.

There's also a kind of transport often very useful that Delphi don't use - and it's message queues.
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 10:52 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Am 16.10.2014 14:22, schrieb Luigi Sandon:
You can now (since XE2) create a stand alone server with HTTPS support.
No web server required.

It could be even less secure than using a real web server :) Someone ever verified how sound and secure Indy HTTP server is? And, as you discovered, there's very little need of using HTTP transport when TCP/IP works as well (and TCP/IP, unlike HTTP, is fully bidirectional).

Self signed certificates obviously can't be used to verify the identity
of the server, but are they really "fake" security? Can't these be used
for encryption and even verification of the server certificate to avoid
man-in-the-middle attacks (just learned about this)?

Because you can't verify a self-signed certificate, it's easy to create your own and play a MTM attack with it. A client has no way to detect if that is the right certificate or not.

Hm? Hasen't every certificate a fingerprint (some checksum which can be
used to check if the bytes forming the certificate match that hash value?).

If yes the client could check that one against a fixed hash value stored
inside the client. It would be really hard for some attacker to create a
false certificate with the same fingerprint.

Of course it has one problem: if the certificate has to be replaced for
some reason the client has to be updated as well in some way to have the
new hash at hand.

Or did I missunderstand something?

Greetings

Markus
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 11:08 AM   in response to: Markus Humm in response to: Markus Humm
Hm? Hasen't every certificate a fingerprint (some checksum which can be
used to check if the bytes forming the certificate match that hash value?).

Sure. You can verify is valid. But any self-signed certificate is valid. You can put whaterver you like in it, say www.google.com, for example, and it's still valid.

Of course it has one problem: if the certificate has to be replaced for
some reason the client has to be updated as well in some way to have the
new hash at hand.

Exactly. Do you usually store each and every certificate of the sites you visit? Of course not. Sure, you can embed a server certificate essential data into a client, and try to match them. This way, you become unable to change the cert unless you deploy a client update. And how can you deploy them safely? I could try to send you a fake update with my certificate.... unless the executable/setup itself is signed with a real certificate.

There's no easy way with PKI and X.509 certificates - they work only with trusted CAs.
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 2:00 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

Exactly. Do you usually store each and every certificate of the sites
you visit? Of course not.

Browsers do. :)

--
Regards,
Bruce McGee
Glooscap Software
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 21, 2014 5:21 AM   in response to: Bruce McGee in response to: Bruce McGee
Browsers do. :)

No. Browser store CAs and use them to check for the certificate validity (unless you decide to trust an untrusted certificate).

For full security, you should also set them to check certificate against Certificate Revocation Lists or similar services - because a certificate may be "valid" but revoked.
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 21, 2014 2:25 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

Browsers do. :)

No. Browser store CAs and use them to check for the certificate
validity (unless you decide to trust an untrusted certificate).

Exactly.

I suppose an application could do the same thing.

--
Regards,
Bruce McGee
Glooscap Software
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 1:59 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Hm? Hasen't every certificate a fingerprint (some checksum which can
be used to check if the bytes forming the certificate match that hash
value?).

If yes the client could check that one against a fixed hash value
stored inside the client. It would be really hard for some attacker
to create a false certificate with the same fingerprint.

Of course it has one problem: if the certificate has to be replaced
for some reason the client has to be updated as well in some way to
have the new hash at hand.

Or did I missunderstand something?

As I understand it, only that first connection is at risk. Once a
client or browser knows to trust the server certificate, self signed or
not, everything is secure. Or as secure as SSL make you.

If you had a secure way to deliver that certificate to the client
(sneaker-net?), I'm not sure why that couldn't work.

--
Regards,
Bruce McGee
Glooscap Software
Jouni Aro

Posts: 86
Registered: 9/4/97
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 2:40 PM   in response to: Bruce McGee in response to: Bruce McGee
On 17/10/14 23:59, Bruce McGee wrote:
Markus Humm wrote:

Hm? Hasen't every certificate a fingerprint (some checksum which can
be used to check if the bytes forming the certificate match that hash
value?).

If yes the client could check that one against a fixed hash value
stored inside the client. It would be really hard for some attacker
to create a false certificate with the same fingerprint.

Of course it has one problem: if the certificate has to be replaced
for some reason the client has to be updated as well in some way to
have the new hash at hand.

Or did I missunderstand something?

As I understand it, only that first connection is at risk. Once a
client or browser knows to trust the server certificate, self signed or
not, everything is secure. Or as secure as SSL make you.

If you had a secure way to deliver that certificate to the client
(sneaker-net?), I'm not sure why that couldn't work.

No, you don't need any secure way to deliver the public certificate to
the client. The whole idea of public key cryptography is that you can
provide the public keys to anyone.

The public key is used to decipher encrypted data that anyone may read
(signatures used to validate that the sender is who he claims to be) and
to send encrypted data that only the specified receiver can decrypt with
his own private key.

If the certificates are used to identify the communicating parties (i.e.
for authentication), and you use self-signed certificates, every party
must accept each certificate of the parties that they trust separately.
With CA signed certificates, applications can trust other parties
automatically, if they trust the signer.

The problem with self-signed certificates is that you must know by some
"external" means that you can trust the party with the self-signed
certificate. If you automatically trust everyone, then there is no
actual authentication.

Even if you trust everyone with any kind of certificate, you can
encrypt communication so that no one can get in between, since you need
the private key to decrypt the messages.
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 3:05 PM   in response to: Jouni Aro in response to: Jouni Aro
Jouni Aro wrote:

The problem with self-signed certificates is that you must know by
some "external" means that you can trust the party with the
self-signed certificate. If you automatically trust everyone, then
there is no actual authentication.

Exactly, and as Bruce McGee noted, this means that the self-signed
certificate has to be securely delivered to the client prior to the
first connection. However, "securely" means "with integrity and
authenticity" in this context, not necessarily "with privacy".
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 19, 2014 6:43 AM   in response to: Henrick Hellström in response to: Henrick Hellström
Henrick Hellström wrote:

Exactly, and as Bruce McGee noted, this means that the self-signed
certificate has to be securely delivered to the client prior to the
first connection. However, "securely" means "with integrity and
authenticity" in this context, not necessarily "with privacy".

Is this a common or recommended practice or something to be avoided at
all costs?

I use self signed certificates for encryption within networks, but not
for external use. For obvious reasons with browsers, but even for
client connections out of concern for a man in the middle attack.

--
Regards,
Bruce McGee
Glooscap Software
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 19, 2014 7:15 AM   in response to: Bruce McGee in response to: Bruce McGee
Bruce McGee wrote:

Henrick Hellström wrote:

Exactly, and as Bruce McGee noted, this means that the self-signed
certificate has to be securely delivered to the client prior to the
first connection. However, "securely" means "with integrity and
authenticity" in this context, not necessarily "with privacy".

Is this a common or recommended practice or something to be avoided at
all costs?

I use self signed certificates for encryption within networks, but not
for external use. For obvious reasons with browsers, but even for
client connections out of concern for a man in the middle attack.

It is a fairly common practice, but something that has to be done right
to be secure. It DOES NOT suffice to just compare the name of the self
signed certificate. The client MUST have prior knowledge of the public
key of self signed certificate, and the client MUST be configured to
actually verify that this public key matches the public key the remote
server uses.

An alternative to using a self-signed certificate, is to use PSK cipher
suites, if supported by the SSL/TLS implementation
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 19, 2014 7:22 AM   in response to: Bruce McGee in response to: Bruce McGee
Bruce McGee wrote:

Henrick Hellström wrote:

Exactly, and as Bruce McGee noted, this means that the self-signed
certificate has to be securely delivered to the client prior to the
first connection. However, "securely" means "with integrity and
authenticity" in this context, not necessarily "with privacy".

Is this a common or recommended practice or something to be avoided at
all costs?

I use self signed certificates for encryption within networks, but not
for external use. For obvious reasons with browsers, but even for
client connections out of concern for a man in the middle attack.

While we're on the subject, I had heard about client certificates to
let a server trust a client.

Do you know if it's advisable or even possible to do this with self
signed certificates?

I hadn't given these much thought until this thread.

Thanks

--
Regards,
Bruce McGee
Glooscap Software
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 19, 2014 7:35 AM   in response to: Bruce McGee in response to: Bruce McGee
Bruce McGee wrote:

While we're on the subject, I had heard about client certificates to
let a server trust a client.

Do you know if it's advisable or even possible to do this with self
signed certificates?

The server will have to have advance knowledge of each such
certificate, and compare the certificate sent by the client to
certificate stored on the server. I guess it is possible if the SSL
implementation allows you to do perform the necessary checks.
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 19, 2014 10:01 AM   in response to: Henrick Hellström in response to: Henrick Hellström
Henrick Hellström wrote:

Bruce McGee wrote:

While we're on the subject, I had heard about client certificates to
let a server trust a client.

Do you know if it's advisable or even possible to do this with self
signed certificates?

The server will have to have advance knowledge of each such
certificate, and compare the certificate sent by the client to
certificate stored on the server. I guess it is possible if the SSL
implementation allows you to do perform the necessary checks.

It looks like I'm going to be more tinkering around with security that
I thought.

And the todo list gets a little longer...

--
Regards,
Bruce McGee
Glooscap Software
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 19, 2014 6:19 AM   in response to: Jouni Aro in response to: Jouni Aro
Jouni Aro wrote:

On 17/10/14 23:59, Bruce McGee wrote:

As I understand it, only that first connection is at risk. Once a
client or browser knows to trust the server certificate, self
signed or not, everything is secure. Or as secure as SSL make you.

If you had a secure way to deliver that certificate to the client
(sneaker-net?), I'm not sure why that couldn't work.

No, you don't need any secure way to deliver the public certificate
to the client. The whole idea of public key cryptography is that you
can provide the public keys to anyone.

You would need a way that can't be spoofed.

--
Regards,
Bruce McGee
Glooscap Software
Jouni Aro

Posts: 86
Registered: 9/4/97
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 19, 2014 7:39 AM   in response to: Bruce McGee in response to: Bruce McGee
On 19/10/14 16:19, Bruce McGee wrote:
Jouni Aro wrote:

On 17/10/14 23:59, Bruce McGee wrote:

As I understand it, only that first connection is at risk. Once a
client or browser knows to trust the server certificate, self
signed or not, everything is secure. Or as secure as SSL make you.

If you had a secure way to deliver that certificate to the client
(sneaker-net?), I'm not sure why that couldn't work.

No, you don't need any secure way to deliver the public certificate
to the client. The whole idea of public key cryptography is that you
can provide the public keys to anyone.

You would need a way that can't be spoofed.

You need also the private key for spoofing (i.e. setting up a rogue
server that claims to be what the actual server is).

But of course, when you accept a public key, you need to know that it is
indeed from the actual server and not from the rogue server. So in that
sense, you need the "external" means to decide that it is trusted.

I suppose, we are on the same track, after all.
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 19, 2014 7:51 AM   in response to: Jouni Aro in response to: Jouni Aro
Jouni Aro wrote:

I suppose, we are on the same track, after all.

I think so.

--
Regards,
Bruce McGee
Glooscap Software
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 1:47 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

You can now (since XE2) create a stand alone server with HTTPS
support. No web server required.

It could be even less secure than using a real web server :) Someone
ever verified how sound and secure Indy HTTP server is?

I assume it's as secure as OpenSSL. Is there any evidence that it's any
less secure than using IIS or Apache?

And, as you
discovered, there's very little need of using HTTP transport when
TCP/IP works as well (and TCP/IP, unlike HTTP, is fully
bidirectional).

I actually discovered the opposite. I use HTTP almost everywhere now.

That doesn't mean TCP/IP connections are invalid for this, or that I go
out of my way to avoid them. I just don't use them as much.

Self signed certificates obviously can't be used to verify the
identity of the server, but are they really "fake" security? Can't
these be used for encryption and even verification of the server
certificate to avoid man-in-the-middle attacks (just learned about
this)?

Because you can't verify a self-signed certificate, it's easy to
create your own and play a MTM attack with it. A client has no way to
detect if that is the right certificate or not.

As mentioned in another reply, public facing services should not use
self signed certificates, especially for a web site.

Otherwise, they seem fine for encryption.

A PKI system relies on CAs to work, it's its weak point. Without a
proper certificate chain validated by a trusted CA, you get
encryption, but not real authentication, so you can use MTM.

Again, it could work in some depolyment, but you need to be very
careful. For example, if you can, it's better to transfer a CA in
some secure way, and then generate server (and clien) certificate
using that CA. This way an attacker can't fake a certificate unless
he obtains a copy of the CA that generated it. Of course you need to
deploy the CA, etc. etc.

I think it works really well in most deployments.

Especially if I'm not writing both the client and server pieces. I'm
thinking mostly about browsers here.

If you're in a domain, or in any network where Kerberos is used, for
example, you have already a a sound and fully working
authentication/authorization infrastructure in place, which doens't
rely on PKI. The downside it could only work in a LAN or through a
VPN, but it can allow for process-level security - transparently.

Sounds useful within a network.

Now that's interesting. It seems like something I should have known.
http://stackoverflow.com/questions/11844630/delphi-ssl-tcp-communication-with-indy-components
Doesn't seem to be exposed in DataSnap for TCP/IP connections,
though.

Yes - it's one of the thing I asked to implement. At least it will
remove web servers and HTTP from the equation.

Now that I know it's possible, I'd like to take advantage of it in
DataSnap.

Is there a QC report?

How do you define "web applications"?

I could define them as mostly client-server stateless applications
using HTTP as the transport and open to a large number of clients.

I can't get my head around that definition.

For me, a web application involves a browser. Everything else is just
communication between a client and an application server, whether it's
UDP, TCP/IP, HTTP or something else.

For example, with a stateless client, your database transactions may
be forced to last as long as a single request. Usually, it could be a
good thing - sometimes, you may need longer transactions across more
calls. That depends on the scenario you have to implement.

This is exactly how I use HTTP connections.

And if I need a longer, dedicated connection, I use TCP/IP.

There's also a kind of transport often very useful that Delphi don't
use - and it's message queues.

I have a vague memory of MSMQ (I hope I'm not way off base), but I have
not had a chance to use message queues.

--
Regards,
Bruce McGee
Glooscap Software
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 21, 2014 6:05 AM   in response to: Bruce McGee in response to: Bruce McGee
I assume it's as secure as OpenSSL. Is there any evidence that it's any
less secure than using IIS or Apache?

No, because there could be vulnerabilities in the HTTP server implementation itself. IIS and Apache undergo a lot of scrutiny, Indy HTTP server not so much. It's open source, sure, but anyone ever made a security audit of its code?

I actually discovered the opposite. I use HTTP almost everywhere now.

If it's good for you, use it, but again, it's not a "one size fits all" approach that makes a library/framework really versatile. Look at WebSocket, is a desperate attempt to make HTTP work like TCP.... while still being able to bypass proxy and ffirewalls - until they became WebSocket aware, so it's just really a stupid attempt to multiplex port 80 and bypass NIC capabilities of handling a lot of TCP/IP processing on board and do it in software. But for a while Google will be able to "steal" more data from you.

Otherwise, they seem fine for encryption.

They still enable an attacker to fake a certificate and sniff the initial handshake and get all he needs to decrypt the transmission. You would need exactly to match a given certificate fingerprint, but it binds an application to just one precise certificate, and I'm not sure if with a self-signed certificate you can fake one anyway to match a given fingerprint - you would need the private key to check it truly, but of course you can't deploy it to clients...

I think it works really well in most deployments.
Especially if I'm not writing both the client and server pieces. I'm
thinking mostly about browsers here.

PKI do work if you have all the needed pieces in place and properly setup. Otherwise, everything crumbles. When Diginotar CA was compromised, the whole company crumbled when OSes and browsers removed its CAs from their trusted ones. All the issued certificates were no longer trusted.

Sounds useful within a network.

It's very useful within a LAN (including VPN access). Because the Kerberos KDC distributes the security tokens (usually when logging on), you don't have to manage certificates and you get both endpoint authentication.

http://qc.embarcadero.com/wc/qcmain.aspx?d=81616

Is there a QC report?

This one refers to it although it's generic about properly setting up an encrypted session across pure TCP:

http://qc.embarcadero.com/wc/qcmain.aspx?d=81617

I could add a specific QC for it.

For me, a web application involves a browser. Everything else is just

Why? That's a common misconception. A browser is actually now just a host of web applications written in HTML+Javascript. So you mean a Youtube app not using a browser to show the video is not a "web application"? Or a Facebook app?

And if I need a longer, dedicated connection, I use TCP/IP.

That's why I need TCP/IP full security as well.

I have a vague memory of MSMQ (I hope I'm not way off base), but I have
not had a chance to use message queues.

MSMQ is the Windows implementation, there are several others, with different features, and there are some good open source cross-platform ones like ZeroMQ.

Message queues allows for asynchronous communication (and it could be transactional), and may be better resilient to communication channel issues (message may be stored until the channel is available again), or for load balancing, publisher/subscriber mechanism, etc. etc. They could solve elegantly some problems that would require a lot of code with a synchronous communication (ot course, that code is in the message library itself... just already written, tested, and ready to use).

If Datasnap could support a message queue transport also, it would become even more versatile.
Mike Margerum

Posts: 590
Registered: 12/1/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 14, 2014 7:39 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Real end-to-end security is a first class requirement today. Could Delphi lag behind, and offer too little, especially at its premium price against competition? Should Embarcadero assign more resources to ensure Delphi applications can stand a real scrutiny from a security perspective? Do you feel you need them, or do you believe you can do without? Or do you just use third party frameworks, and Delphi should just dump its ones and save resources to develop something else?

I've given up on using Delphi for my middle tier. Moving my python web
server code to either node or go

I'm also not using it for mobile because people still can't sign their
apps weeks later for the store. not workable.

I'll continue to use delphi for what its good at. VCL desktop apps. I
wish now that i hadn't upgraded to enterprise and instead spent that
money on something more useful.
Nick Hodges

Posts: 2,414
Registered: 9/22/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 14, 2014 7:57 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

Why Delphi doesn't offer a good cryptographic library,

I can answer that -- US law makes it almost impossible -- and extremely
risky -- to ship encryption outside of US borders.

--
Nick
Delphi Programming is Fun
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 14, 2014 8:39 AM   in response to: Nick Hodges in response to: Nick Hodges
I can answer that -- US law makes it almost impossible -- and extremely
risky -- to ship encryption outside of US borders.

Do you know that it was relaxed years ago (http://www.gpo.gov/fdsys/pkg/FR-1996-11-19/pdf/96-29692.pdf)? But do you mean that Microsoft, Apple, Oracle, Mozilla, RedHat, Google, etc. are breaking US laws? Oh my god, let's call the FBI, CIA, NSA! Jail all of them, damned terrorists!

C'mon, you and BorInCodeDero :-P should really stop using lame excuses. And if Delphi used CryptoAPI it wasn't exporting any encryption at all, at most they could arrest Ballmer or Nadella, if that was the main concern.

Also you mean that Interbase encryption is fake because "it almost impossible -- and extremely risky -- to ship encryption outside of US borders"? And thereby Embarcadero is lying to its customer because there's no real encryption in Interbase?

But you're right, today using NSA approved cryptographic technology is very risky for non US citizens and company, there's a big chance there are built-in backdoors to snoop data...

Edited by: Luigi Sandon on Oct 14, 2014 8:14 PM
Nick Hodges

Posts: 2,414
Registered: 9/22/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 14, 2014 1:36 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

I may be mistaken, but I believe you are missing the distinction
between applications that do encryption and actually shipping code and
tools that do encryption.

Love the sarcasm, BTW. It's so grown up.

--
Nick
Delphi Programming is Fun

Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 14, 2014 2:13 PM   in response to: Nick Hodges in response to: Nick Hodges
I may be mistaken, but I believe you are missing the distinction
between applications that do encryption and actually shipping code and
tools that do encryption.

I believe you're missing much more. When those rules were in place, many application outside US - i.e. web browsers (IE used only 56 bit encryption in export versions of Windows then) - had crippled encryption too. There's actually no difference if your database encrypts data or your application does it. The US rules were against exporting strong cryptography in any form, after all you don't really care if a enemy use a ready made application to encrypt a message, or write its own. Of course the Internet made trying to limit it pretty useless, and Internet commerce does require strong encryption to work or nobody trust it (and that's one of the stronger reason those limits were lifted). Do you believe RSA doesn't sell its encryption toolkits outside the US, for example? Moreover most algorithms are public, thereby there's very little to protect. BTW, AES was developed by two Belgians... probably EU should have forbidden strong cryptography export towards the US....

And still you can't explain why MS, Oracle, Apple, Google etc. can deliver OS libraries, development tools and SDKs that actually ship code and tools that do strong encryption - it doesn't look so risky or impossible. Sure, when you download you have to tell you're not in North Korea or Iran, but that's all.

And about the NSA, it's not sarcasm. Our business skyrocketed since outside US a lot of people no longer trust US companies to protect their data, and found you don't only have to defend from your "historical" enemies, but from those you though were on your side too....
Nick Hodges

Posts: 2,414
Registered: 9/22/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 14, 2014 5:02 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

And still you can't explain why MS, Oracle, Apple, Google etc. can
deliver OS libraries, development tools and SDKs that actually ship
code and tools that do strong encryption - it doesn't look so risky
or impossible. Sure, when you download you have to tell you're not in
North Korea or Iran, but that's all.

Okay. I was wrong, I guess.

--
Nick
Delphi Programming is Fun
Eli M

Posts: 1,346
Registered: 11/9/13
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 14, 2014 5:18 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 14, 2014 2:18 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

C'mon, you and BorInCodeDero :-P should really stop using lame
excuses.

Easy there. I thought we were trying the no sniping thing, at least in
this thread.

It's a fair question, but Nick also gave a fair answer. Export
restrictions have been relaxed, but are still in place.

--
Regards,
Bruce McGee
Glooscap Software
Jouni Aro

Posts: 86
Registered: 9/4/97
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 15, 2014 12:47 AM   in response to: Bruce McGee in response to: Bruce McGee
On 15/10/14 00:18, Bruce McGee wrote:
Luigi Sandon wrote:

C'mon, you and BorInCodeDero :-P should really stop using lame
excuses.

Easy there. I thought we were trying the no sniping thing, at least in
this thread.

It's a fair question, but Nick also gave a fair answer. Export
restrictions have been relaxed, but are still in place.

They are, but they don't concern security any more. Oracle is still
restricting the Java default security, though, but they only restrict
because of import restrictions:

http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html

Import Limits on Cryptographic Algorithms
Due to import regulations in some countries, the Oracle implementation provides a default cryptographic jurisdiction policy file that limits the strength of cryptographic algorithms. Here are the maximum key sizes allowed by this "strong" version of the jurisdiction policy files:

Algorithm Maximum Keysize
DES 64
DESede *
RC2 128
RC4 128
RC5 128
RSA *
all others 128
If stronger algorithms are needed (for example, AES with 256-bit keys), the JCE Unlimited Strength Jurisdiction Policy Files must be obtained and installed in the JDK/JRE.

It is the user's responsibility to verify that this action is permissible under local regulations.

There are countries that impose limits on security, but I haven't found
any up-to-date list of those.

.NET provides 256-bit security out-of-the-box, so I suppose using the
security features of .NET is just considered as the responsibility of
the user/developer without saying it explicitly. Oracle's restrictions
have the origin in the export regulations, but nowadays the
'US_export.policy' defines unlimited security.

I would also like to see Delphi to support crypto out of the box. We are
working on OPC UA libraries. OPC UA includes (RSA certificates + 128/256
bit AES) encryption built in the communication protocol - and provides
an "optimized" binary protocol for client/server based communication.
Otherwise it's generally a higher level protocol (incl. semantic
modeling of industrial data), and defines different transport protocols
- but all this goes out of scope here.

We have been considering Delphi support for a long time. Embracing the
existing C implementation will be the most probable solution, but I
think the native Delphi one would be the most desirable.

Current market situation has not enabled to start the development for
Delphi, at least not yet. The C stack is using openssl, so wrapping that
would be the cross-platform solution, if done today. Anyway, Having a
(cross-platform) crypto library out of the box, would indeed help,
should we go for a native Delphi implementation.

Eli M

Posts: 1,346
Registered: 11/9/13
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 15, 2014 7:42 AM   in response to: Jouni Aro in response to: Jouni Aro
Embarcadero just finished funding the upgrade for Lockbox (an open source Delphi crypto lib) to XE7 w/ cross platform support.

...AES, DES, 3DES, Blowfish, Twofish, SHA, MD5, a variety of chaining modes, RSA digital signature...

http://sourceforge.net/projects/turbopowerlockboxnew/

http://blog.kassebaum.eu/?p=379
Jouni Aro

Posts: 86
Registered: 9/4/97
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 15, 2014 8:03 AM   in response to: Eli M in response to: Eli M
On 15/10/14 17:42, Eli M wrote:
Embarcadero just finished funding the upgrade for Lockbox (an open source Delphi crypto lib) to XE7 w/ cross platform support.

...AES, DES, 3DES, Blowfish, Twofish, SHA, MD5, a variety of chaining modes, RSA digital signature...

http://sourceforge.net/projects/turbopowerlockboxnew/

http://blog.kassebaum.eu/?p=379

Sounds very good! Thanks for the heads up.
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 15, 2014 6:35 PM   in response to: Eli M in response to: Eli M
Eli M wrote:

Embarcadero just finished funding the upgrade for Lockbox (an open
source Delphi crypto lib) to XE7 w/ cross platform support.

...AES, DES, 3DES, Blowfish, Twofish, SHA, MD5, a variety of chaining
modes, RSA digital signature...

http://sourceforge.net/projects/turbopowerlockboxnew/

http://blog.kassebaum.eu/?p=379

I saw the announcement, but missed that it was cross platform.

Outstanding!

--
Regards,
Bruce McGee
Glooscap Software
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 4:25 AM   in response to: Eli M in response to: Eli M
Embarcadero just finished funding the upgrade for Lockbox (an open source Delphi crypto lib) to XE7 w/ cross platform support.

When it comes to security - especially encryption -, it's far better not to rely on small, limited and unknown quality efforts - especially by someone who also attempted to change the license to GPLv3 when he had no right to do it. You need a sound, well tested library. Even OpenSSL showed big flaws, and has far better support. There are some encryption library for Delphi, yet, if you rely on OS support, if a law/vuln is fixed, your application automatically gets them. If you deploy your code, it's up to you to release fixes.

But encryption algorithms are just one part to security. The issue in Datasnap is you can't encrypt data properly even if you have the algorithms, because what is missing is a way to create keys (a good rundom number generator, for example - even LockBox uses CryptoAPI for that...) and exchange them securely. And there's still the authentication/authorization issue - which requires the capability to carry around information - securely - about who is calling, in a way that is veriiable on the other side.
Eli M

Posts: 1,346
Registered: 11/9/13
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 6:55 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Which is why my suggestion to use SSH tunneling for DataSnap TCP/IP seems like the best approach. It's an industry standard protocol which has the security mechanisms you were looking for. Seems like exposing the SSL support for the TCP/IP version is also a good idea as an additional option since Indy already supports it.

Luigi Sandon wrote:
When it comes to security - especially encryption -, it's far better not to rely on small, limited and unknown quality efforts - especially by someone who also attempted to change the license to GPLv3 when he had no right to do it. You need a sound, well tested library.
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 11:10 AM   in response to: Eli M in response to: Eli M
Which is why my suggestion to use SSH tunneling for DataSnap TCP/IP seems like the best approach.

SSH is almost non-existent under Windows and has its trouble as well with key exchange. A VPN tunnel is far more standard - but again requires more software to work, and more configurations. Also, you need to initialize the tunnel somehow.
Eli M

Posts: 1,346
Registered: 11/9/13
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 2:08 PM   in response to: Luigi Sandon in response to: Luigi Sandon
I use SSH (SFTP) every day from and to Windows machines for secure file transfers. As linked in my previous post IP*Works provides all the components to do so as well.
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 21, 2014 6:12 AM   in response to: Eli M in response to: Eli M
I use SSH (SFTP) every day from and to Windows machines for secure file transfers. As linked in my previous post IP*Works provides all the components to do so as well.

Which SSH Windows server do you use? Also, how do you handle and verify SSH keys?

Moreover, in Windows, SMB (you can encrypt the channel if you like) doesn't suffer from NFS limitations (and SMB2/3 are far faster and less verbose protocols), and Remote Desktop offers what SSH does - so there's very little need to use SSH on Windows unless you need *nix interoperability.
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 15, 2014 6:34 PM   in response to: Jouni Aro in response to: Jouni Aro
Jouni Aro wrote:

On 15/10/14 00:18, Bruce McGee wrote:

It's a fair question, but Nick also gave a fair answer. Export
restrictions have been relaxed, but are still in place.

They are, but they don't concern security any more.

It still seems to be a bit of a rat's nest.

http://www.cryptolaw.org/

There are countries that impose limits on security, but I haven't
found any up-to-date list of those.

I saw this one.

http://en.wikipedia.org/wiki/Restrictions_on_the_import_of_cryptography

--
Regards,
Bruce McGee
Glooscap Software
Jouni Aro

Posts: 86
Registered: 9/4/97
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 4:39 AM   in response to: Bruce McGee in response to: Bruce McGee
On 16/10/14 04:34, Bruce McGee wrote:
Jouni Aro wrote:

On 15/10/14 00:18, Bruce McGee wrote:

It's a fair question, but Nick also gave a fair answer. Export
restrictions have been relaxed, but are still in place.

They are, but they don't concern security any more.

It still seems to be a bit of a rat's nest.

http://www.cryptolaw.org/

There are countries that impose limits on security, but I haven't
found any up-to-date list of those.

I saw this one.

http://en.wikipedia.org/wiki/Restrictions_on_the_import_of_cryptography

Yes, it is very difficult to decipher what the exact status in each
country is - even with these resources (i.e. what level of encryption is
limited or prohibited). This gives probably the best overview:

http://www.cryptolaw.org/cls-sum.htm

I really tried to figure out why Oracle is applying the restrictions a
while ago, and found out that the import controls is the only reason.
They also have a task in their records that they could remove the
restrictions, but did not do that for Java 8, yet - probably because the
lawmen did not manage to give the final green light to this either, in
that time frame.

Also since .NET doesn't impose any restrictions, it seems a bit odd.

However, the US Export controls obviously do not restrict the crypto
export at all. Although according to CryptoLaw, you mayneed to have some
kind of license for that, but I admit I don't understand the details of
the current status from this:

http://www.cryptolaw.org/cls2.htm#us_1
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 4:31 PM   in response to: Jouni Aro in response to: Jouni Aro
Jouni Aro wrote:

However, the US Export controls obviously do not restrict the crypto
export at all. Although according to CryptoLaw, you mayneed to have
some kind of license for that, but I admit I don't understand the
details of the current status from this:

http://www.cryptolaw.org/cls2.htm#us_1

If you need a license, then there are restrictions, but not necessarily
a prohibition.

If taking advantage of OpenSSL lets them side step this, then more
power to them.

--
Regards,
Bruce McGee
Glooscap Software
Jouni Aro

Posts: 86
Registered: 9/4/97
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 6:00 AM   in response to: Bruce McGee in response to: Bruce McGee
On 17/10/14 02:31, Bruce McGee wrote:
Jouni Aro wrote:

However, the US Export controls obviously do not restrict the crypto
export at all. Although according to CryptoLaw, you mayneed to have
some kind of license for that, but I admit I don't understand the
details of the current status from this:

http://www.cryptolaw.org/cls2.htm#us_1

If you need a license, then there are restrictions, but not necessarily
a prohibition.

Apple restricts distributing applications that use encryption from the
App Store with this rule:

https://developer.apple.com/programs/terms/mac/mac_program_agreement_20140602.pdf

Schedule 1

2.3 You hereby certify that all of the Licensed Applications You deliver to Apple under this Schedule 1 are authorized for export from the United States to each of the countries designated by You under Section 2.1 hereof, in accordance with the requirements of all applicable laws, including but not limited to the United States Export Administration Regulations, 15 C.F.R. Parts 730-774 and the International Traffic in Arms Regulations 22 C.F.R. Parts 120-130. Without limiting the generality of this Section 2.3, You certify that (i) none of the Licensed Applications contains, uses or supports any data encryption or cryptographic functions; or (ii) in the event that any Mac App Store App contains, uses or supports any such data encryption or cryptographic functionality, You certify that You have complied with the United States Export Administration Regulations, and are in possession of, and will upon request provide Apple with a PDF copy of Your Encryption Registration Number (ERN), or
export classification ruling (CCATS) issued by the United States Commerce Department, Bureau of Industry and Security and PDF copies of appropriate authorizations from other countries that mandate import authorizations for that Licensed Application, as required. You acknowledge that Apple is relying upon Your certification in this Section 2.3 in allowing end-users to access and download the Licensed Applications under this Schedule 1. Except as provided in this Section 2.3, Apple will be responsible for compliance with the requirements of the Export Administration Regulations in allowing end-users to access and download the Licensed Applications under this Schedule 1.
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 6:14 AM   in response to: Jouni Aro in response to: Jouni Aro
Jouni Aro wrote:
Apple restricts distributing applications that use encryption from the
App Store with this rule:

Apparently there are similar clauses for the Microsoft and Google Play stores.

Nuts. I was just beginning to be convinced that encryption was less onerous than I thought, but it still seems to be pretty thorny.

I'll need to learn more, and this isn't the thing that I wanted to be spending my time on.

--
Regards
Bruce McGee
Glooscap Software
Jouni Aro

Posts: 86
Registered: 9/4/97
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 8:27 AM   in response to: Bruce McGee in response to: Bruce McGee
On 17/10/14 16:14, Bruce McGee wrote:
Jouni Aro wrote:
Apple restricts distributing applications that use encryption from the
App Store with this rule:

Apparently there are similar clauses for the Microsoft and Google Play stores.

Nuts. I was just beginning to be convinced that encryption was less onerous than I thought, but it still seems to be pretty thorny.

I'll need to learn more, and this isn't the thing that I wanted to be spending my time on.

Well, it could just mean that you need to apply for an ERN from the US
government. Once you get that, you may do whatever you like.

The question is, what does that really involve. Apparently, Oracle and
Microsoft may provide security frameworks abroad, so the only thing may
be that they just want to get you on a list of entities using
encryption. I don't think it would be an issue for Embarcadero to get an
ERN, if they don't have one already.
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 8:35 AM   in response to: Jouni Aro in response to: Jouni Aro
Jouni Aro wrote:
Well, it could just mean that you need to apply for an ERN from the US
government. Once you get that, you may do whatever you like.

The question is, what does that really involve. Apparently, Oracle and
Microsoft may provide security frameworks abroad, so the only thing may
be that they just want to get you on a list of entities using
encryption. I don't think it would be an issue for Embarcadero to get an
ERN, if they don't have one already.

As I wrote elsewhere, if that's all it takes, then it makes sense. I'm skeptical, but will keep an open mind.

Then the question is whether it makes sense to acquire an encryption library. I really don't think they should build one from scratch.

I kind of prefer the idea of them wrapping an existing library instead and shipping that wrapper with Delphi. Luigi even filed a helpful QC report.

http://qc.embarcadero.com/wc/qcmain.aspx?d=128340

--
Regards
Bruce McGee
Glooscap Software
Jouni Aro

Posts: 86
Registered: 9/4/97
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 2:19 PM   in response to: Bruce McGee in response to: Bruce McGee
On 17/10/14 18:35, Bruce McGee wrote:
Jouni Aro wrote:
Well, it could just mean that you need to apply for an ERN from the US
government. Once you get that, you may do whatever you like.

The question is, what does that really involve. Apparently, Oracle and
Microsoft may provide security frameworks abroad, so the only thing may
be that they just want to get you on a list of entities using
encryption. I don't think it would be an issue for Embarcadero to get an
ERN, if they don't have one already.

As I wrote elsewhere, if that's all it takes, then it makes sense. I'm skeptical, but will keep an open mind.

Here's the process:

http://www.bis.doc.gov/index.php/policy-guidance/encryption

Took me a while to get a proper understanding but it's beginning to look
pretty clear, after all - or at least I think so <g>. In general, I get
it that hardware and software whose primary purpose is to provide
cryptography or strongly (>=64 bit) encrypted communications or storage
need to apply for an ERN.

Most applications that only use cryptography do not need to file a
request as they fall under "Note 4":

http://www.bis.doc.gov/index.php/policy-guidance/encryption/encryption-faqs#15

Then the question is whether it makes sense to acquire an encryption library. I really don't think they should build one from scratch.

I kind of prefer the idea of them wrapping an existing library instead and shipping that wrapper with Delphi. Luigi even filed a helpful QC report.

http://qc.embarcadero.com/wc/qcmain.aspx?d=128340

Yes, I would also like that approach. Or make it possible to use
CryptoAPI or LockBox, for example. I don't think anyone suggested that
they would write their own implementation, since that is a tedious task
and completely unnecessary.

We have a similar case in Java. Oracle is providing a "standard"
implementation, but we are also using Bouncy Castle, which is the "de
facto" open source library.
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 2, 2015 2:28 PM   in response to: Bruce McGee in response to: Bruce McGee
Bruce McGee wrote:


Embarcadero updated some details on their 2015 road map. I wonder if
this is the last item on page 9.

http://community.embarcadero.com/index.php/blogs/entry/rad-studio-2015-roadmap

--
Regards,
Bruce McGee
Glooscap Software
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 5:52 AM   in response to: Jouni Aro in response to: Jouni Aro
They are, but they don't concern security any more. Oracle is still
restricting the Java default security, though, but they only restrict
because of import restrictions:

http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html

Exactly:

"JCE for Java SE 7 has been through the U.S. export review process. The JCE framework, along with the various JCE providers that come standard with it (SunJCE, SunEC, SunPKCS11, SunMSCAPI, etc), is exportable."

"Due to the import restrictions of some countries"

If stronger algorithms are needed (for example, AES with 256-bit keys), the JCE Unlimited Strength Jurisdiction Policy Files must be obtained and installed in the JDK/JRE.
It is the user's responsibility to verify that this action is permissible under local regulations.

This has more to do with some countries that don't like strong encryption to be used by their citizens, than US export restrictions.

There are countries that impose limits on security, but I haven't found
any up-to-date list of those.

I guess you should look in Middle East or Far East, I guess.

have the origin in the export regulations, but nowadays the
'US_export.policy' defines unlimited security.

There are still some limitations - and I agree that as usual gov rules are not so simple like we would like them - but for most commercial encryption is not "almost impossibile and very risky". Especially when you can get the same encryption
capabilities from other available toolkits

Anyway, as I said, the problem is not really the algorithm itself - it's the lack of the plumbing to ensure a good algorithm can be uised, even without supplying it. Look at Indy - it doesn't come by default with OpenSSL, but can use it easily (and hopefully properly).

Delphi, at least not yet. The C stack is using openssl, so wrapping that

OpenSSL is undergoing deep changes:

https://www.openssl.org/about/roadmap.html

If you read about the platform strategy,

"There will be a defined set of primary platforms. The primary platforms will be Linux and FreeBSD. A primary platform is one where most development occurs.
In addition there will be a list of secondary platforms which are supported by the development team."

Windows will be still supported, but the focus will be on Linux/FreeBSD.

Because well written encryption library are interoperable - you can easily have a CryptoAPI client talking to an OpenSSL server without issues - I'm not sure if the correct way to cross-platform security is to use a cross-platform library which is not a first citizen one in one OS, instead of using the native one.

Like Firemonkey wraps different graphic libraries on different platforms, I can't see why Delphi can design an "abstract" encryption library that could wrap CryptoAPI or OpenSSL, ensuring code cross compatiblity, while ensuring the native library is used - to ensure up-to-date code.
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 10:56 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Am 16.10.2014 14:52, schrieb Luigi Sandon:


Like Firemonkey wraps different graphic libraries on different platforms, I can't see why Delphi can design an "abstract" encryption library that could wrap CryptoAPI or OpenSSL, ensuring code cross compatiblity, while ensuring the native library is used - to ensure up-to-date code.

Hello,

put that request as feature request into QC and give us the ticket number.

Greetings

Markus
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 12:06 PM   in response to: Markus Humm in response to: Markus Humm
put that request as feature request into QC and give us the ticket number.

Good idea:

Add a cryptographic wrapper library that can use different cryptographic backends

#128340

http://qc.embarcadero.com/wc/qcmain.aspx?d=128340

Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 1:18 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Am 16.10.2014 21:06, schrieb Luigi Sandon:
put that request as feature request into QC and give us the ticket number.

Good idea:

Add a cryptographic wrapper library that can use different cryptographic backends

#128340

http://qc.embarcadero.com/wc/qcmain.aspx?d=128340


Hello,

I gave you a few votes. I hope you gave yourself 10 votes ;-)

Greetings

Markus
Jouni Aro

Posts: 86
Registered: 9/4/97
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 12:31 PM   in response to: Luigi Sandon in response to: Luigi Sandon
On 16/10/14 15:52, Luigi Sandon wrote:
This has more to do with some countries that don't like strong encryption to be used by their citizens, than US export restrictions.

Yes, that's clear.

There are countries that impose limits on security, but I haven't found
any up-to-date list of those.

I guess you should look in Middle East or Far East, I guess.

Yes, I know the Asian countries are the ones. But as I said, there is no
clear list - and even Oracle defines it the responsibility of the users
to find out if they may use strong encryption.

OpenSSL is undergoing deep changes:

https://www.openssl.org/about/roadmap.html

If you read about the platform strategy,

"There will be a defined set of primary platforms. The primary platforms will be Linux and FreeBSD. A primary platform is one where most development occurs.
In addition there will be a list of secondary platforms which are supported by the development team."

Windows will be still supported, but the focus will be on Linux/FreeBSD.

OK, good to know. I haven't followed OpenSSL so closely, since Java has
its own security libraries and also its own SSL implementation.

Because well written encryption library are interoperable - you can easily have a CryptoAPI client talking to an OpenSSL server without issues - I'm not sure if the correct way to cross-platform security is to use a cross-platform library which is not a first citizen one in one OS, instead of using the native one.

Hmm, I don't quite understand what the platform specific issues are,
except for the random number generators, which are different. Can you
elaborate?

Like Firemonkey wraps different graphic libraries on different platforms, I can't see why Delphi can design an "abstract" encryption library that could wrap CryptoAPI or OpenSSL, ensuring code cross compatiblity, while ensuring the native library is used - to ensure up-to-date code.

That would the best design, yes, that you would a common interface and
validated implementations of it.

Sun/Oracle has defined a security framework for Java and they have also
validated and signed those libraries. You cannot access unsigned
libraries via the security framework.
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 12:36 AM   in response to: Bruce McGee in response to: Bruce McGee
It's a fair question, but Nick also gave a fair answer. Export
restrictions have been relaxed, but are still in place.

Nick gave an answer that could have been fair many years ago. Now it's just an excuse and a one that doesn't stands.

Every other development tool, library, application, etc. etc. does support encryption and does support strong encryption. So cryptography export restrictions are not the problem, don't try to move again the focus away from the real issue.

Only Delphi developers are left with a remoting system that doesn't protect data in transit properly.
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 2:43 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

It's a fair question, but Nick also gave a fair answer. Export
restrictions have been relaxed, but are still in place.

Nick gave an answer that could have been fair many years ago. Now
it's just an excuse and a one that doesn't stands.

Every other development tool, library, application, etc. etc. does
support encryption and does support strong encryption. So
cryptography export restrictions are not the problem, don't try to
move again the focus away from the real issue.

The current state of import and export restrictions is still a legal
minefield.

I don't understand the problem with them wrapping another well known
library. You yourself suggested they wrap Microsoft's.

Only Delphi developers are left with a remoting system that doesn't
protect data in transit properly.

Please don't use hyperbole.

--
Regards,
Bruce McGee
Glooscap Software
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 12:16 PM   in response to: Bruce McGee in response to: Bruce McGee
The current state of import and export restrictions is still a legal
minefield.

Minefield is an hyperbole as well. It looks you may need to register via a webform sending a PDF... I'm sure in the area around San Francisco should not be difficult to get a legal expert about how to do it...

We just send some appliance around the world (which do include encryption...) and our export department took care of all the paperwork needed.

I don't understand the problem with them wrapping another well known
library. You yourself suggested they wrap Microsoft's.

No, wrapping a well known library is a good idea, reinventing the wheel in such a field require highly skilled personnel. If they wrap the OS native library, even better, because you get automatic updates.

Please don't use hyperbole.

As long as you use a correctly configured web server with a real certificate you get reasonable security (especially if you don't need client authentication and impersonating the client on the server). Otherwise you don't really get security.

Hope you disabled SSLv3 across all your server and clients, today.... <G>
Nick Hodges

Posts: 2,414
Registered: 9/22/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 1:05 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

We just send some appliance around the world (which do include
encryption...) and our export department took care of all the
paperwork needed.

You are in Italy, no? WOuldn't such an export have to follow Italian
and not American laws?

How have you come by your expertise in American encryption export law?
I'm curious.

--
Nick
Delphi Programming is Fun
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 1:21 PM   in response to: Nick Hodges in response to: Nick Hodges
Am 16.10.2014 22:05, schrieb Nick Hodges:
Luigi Sandon wrote:

We just send some appliance around the world (which do include
encryption...) and our export department took care of all the
paperwork needed.

You are in Italy, no? WOuldn't such an export have to follow Italian
and not American laws?

How have you come by your expertise in American encryption export law?
I'm curious.

Hello,

not sure if I overlooked something here, but when I export something I
automatically import that same something elsewhere... ;-)
And as already found out by some other posters imports are quite
regulated in some countries as well.

Greetings

Markus
Nick Hodges

Posts: 2,414
Registered: 9/22/99
Re: Security of Delphi remoting frameworks [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 1:22 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

not sure if I overlooked something here, but when I export something I
automatically import that same something elsewhere... ;-)

Uhm, yeah, of course.

And as already found out by some other posters imports are quite
regulated in some countries as well.

Okay.

--
Nick
Delphi Programming is Fun
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 2:49 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

The current state of import and export restrictions is still a legal
minefield.

Minefield is an hyperbole as well.

I wouldn't have thought so, but I also described it as a "rat's nest",
which certainly qualifies.

Between import and export hurdles, I'll go back to describing it as
non-trivial.

It looks you may need to register
via a webform sending a PDF...

If that's really all there is to it, and there are no other gotchas,
then there shouldn't be any problem if Embarcadero decides to acquire
and ship some encryption library.

I think there might be more to it, though.

--
Regards,
Bruce McGee
Glooscap Software
Enquiring Mind

Posts: 88
Registered: 10/6/08
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 5:27 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:
I can answer that -- US law makes it almost impossible -- and extremely
risky -- to ship encryption outside of US borders.

Do you know that it was relaxed years ago (http://www.gpo.gov/fdsys/pkg/FR-1996-11-19/pdf/96-29692.pdf)? But do you mean that Microsoft, Apple, Oracle, Mozilla, RedHat, Google, etc. are breaking US laws? Oh my god, let's call the FBI, CIA, NSA! Jail all of them, damned terrorists!

C'mon, you and BorInCodeDero :-P should really stop using lame excuses. And if Delphi used CryptoAPI it wasn't exporting any encryption at all, at most they could arrest Ballmer or Nadella, if that was the main concern.

Also you mean that Interbase encryption is fake because "it almost impossible -- and extremely risky -- to ship encryption outside of US borders"? And thereby Embarcadero is lying to its customer because there's no real encryption in Interbase?

But you're right, today using NSA approved cryptographic technology is very risky for non US citizens and company, there's a big chance there are built-in backdoors to snoop data...
IMHO this notion that all US encryption software contains a back-door is a bit of a paranoid myth blown out of all proportion by the media frenzy triggered by the Edward Snowden revelations. All cryptographic algorithms are theoretically breakable given enough time and computing power. Some algorithms have known back-doors, others do not. Export of cryptographic algorithms from the USA is not as far as I am aware illegal, unless they are secret algorithms private to the intelligence services. The NSA publishes the specification of many cryptographic algorithms. So these by definition are not secret and are therefore freely accessible to be implemented and/or used by anybody, anywhere. As I myself did in the case of AES, working from the specifications published by NSA. AES is clearly not a secret US algorithm as it was developed by a non-US-based team that won a tender issued by NSA to come up with a more secure algorithm that those in general use at the time. Many encryption and hashing algorithms are freely published by the NSA, in books and elsewhere. The current philosophy of cryptographic protection is that is should not depend on not having access to a secret encryption algorithm, but only on the strength of the possibly public algorithm and the keys used.

With regard to the question of whether or not Delphi should build in encryption to network communications using some specific cryptographic library, say the Windows CryptoAPI or some other library like LockBox, IMHO it is not advisable. The program developer should be able to use whichever cryptographic library and algorithm he/she considers appropriate for the application. System and third party libraries are liable to change in time, and may incorporate errors or vulnerabilities that more capable libraries avoid. That said. since Delphi purports to be a Windows software development tool, I think it should provide as comprehensive a Pascal library wrapping of the Windows libraries as possible. I therefore agree that it would be nice if it were to make available CryptoAPI and other specialist Windows libraries, so that users may use them if they see fit. Returning to the transmission of data over open networks, there is no harm in Delphi applying a default virtual encryption algorithm, provided that the developer is free to override the default algorithm with another of his/her choice.

If Delphi were to use the Windows CryptoAPI for message encryption, that would build in yet another unnecessary system dependency that would hinder platform independence. Cryptographic belongs to the realm of application code, not system code, IMHO. Hence a cryptographic library in Pascal that can be compiled into the code of any target platform is the right way to go.

EM

Edited by: Enquiring Mind on Oct 16, 2014 1:29 PM
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 6:01 AM   in response to: Enquiring Mind in response to: Enquiring Mind
IMHO this notion that all US encryption software contains a back-door is a bit of a paranoid myth blown out of all proportion by the media frenzy triggered by the Edward Snowden revelations.

True or not, the NSA actions triggered a lot of suspicion - trust has been irreparably damaged.

Some algorithms have known back-doors, others do not.

You can always implement a known algorithm in a given product in a way to allow a backdoor or lower its security - and you can discover it only reverse engineering it fully.

If Delphi were to use the Windows CryptoAPI for message encryption, that would build in yet another unnecessary system dependency that would hinder platform independence.

It could wrap different libraries with a unified internal API, as it already does for other libraries.

Cryptographic belongs to the realm of application code, not system code,

No - this is a big mistake. Security needs to be always up-to-date, or it may become vulnerable - unless you can ensure you keep your application code up-to-date.

IMHO. Hence a cryptographic library in Pascal that can be compiled into the code of any target platform is the right way to go.

That would mean that someone with the righ skill needs to maintain it. Especially since Delphi maintanins barely the last release for six month, if it had its own implemented libary there's a real risk they get outdated and vulnerable very soon. Sure, it could become another marketing trick to sell new versions, but it's something I wouldn't like to be bound to. That's a worst dependency than being bound to OS libraries...
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 6:25 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

Cryptographic belongs to the realm of application code, not system
code,

No - this is a big mistake. Security needs to be always up-to-date,
or it may become vulnerable - unless you can ensure you keep your
application code up-to-date.

Neither the question, nor the answer to the question, is that
clear-cut. You have to balance several considerations. For instance, if
you are deploying to an organization that still has Windows XP and IE6
installed on all computers on the internal network, it would obviously
be a very bad idea to rely solely on OS upgrades.
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 11:01 AM   in response to: Henrick Hellström in response to: Henrick Hellström
Am 16.10.2014 15:25, schrieb Henrick Hellström:
Luigi Sandon wrote:

Cryptographic belongs to the realm of application code, not system
code,

No - this is a big mistake. Security needs to be always up-to-date,
or it may become vulnerable - unless you can ensure you keep your
application code up-to-date.

Neither the question, nor the answer to the question, is that
clear-cut. You have to balance several considerations. For instance, if
you are deploying to an organization that still has Windows XP and IE6
installed on all computers on the internal network, it would obviously
be a very bad idea to rely solely on OS upgrades.

Hello,

it is a very bad idea of that organization to still deploy Windows XP
and IE6. For XP IE8 is already available and newer. So they do not even
deploy the minimum freely possible.

Does the organization really have a need to continue using IE6?
(even if they shouldn't have te ressources for a Windows 7 or 8
migration - which sounds quite bad)

Greetings

Markus
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 11:26 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Am 16.10.2014 15:25, schrieb Henrick Hellström:
Neither the question, nor the answer to the question, is that
clear-cut. You have to balance several considerations. For
instance, if you are deploying to an organization that still has
Windows XP and IE6 installed on all computers on the internal
network, it would obviously be a very bad idea to rely solely on OS
upgrades.

Hello,

it is a very bad idea of that organization to still deploy Windows XP
and IE6. For XP IE8 is already available and newer. So they do not
even deploy the minimum freely possible.

That is completely irrelevant from the perspective of the software
developer who is hired to write software for such an organization.
Their IT policies might not be open to discussion in the first place.
Your job is to help them find the best compromice given their
requirements; not speculate about how their issues might be solved in
the best of worlds.

That said, the situation wouldn't be so much different, should the
organization have all Windows 7 or Windows 8 on their PCs. Such
organization typically don't allow Windows Update to be run
independently on each PC. They probably don't even allow their users to
install any software on their own, and restrict internet access to a
bare minimum.

Consequently, given how they typically do push out OS updates and
software updates, it doesn't really matter if the update comes with the
OS or with the independent software.
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 12:24 PM   in response to: Henrick Hellström in response to: Henrick Hellström
That is completely irrelevant from the perspective of the software
developer who is hired to write software for such an organization.

There could be "corner case" when you need to deviate from the standard, sensible approach.
I'm not saying you should not be able to use other encryption libraries in Delphi, but using the OS one is more often than not the correct approach.
Note that some older OS may not even support latest version of some libraries because they may be compiled too with compilers that no longer support that OSes... you may need to compile it yourself, and resolve any issue arising.

organization typically don't allow Windows Update to be run
independently on each PC. They probably don't even allow their users to

Sure. They use WSUS to centralize updates and approvals. And schedule PCs to receive security updates.

install any software on their own, and restrict internet access to a
bare minimum.

Exactly. That means that updating non-OS libraries becomes even more difficult, while OS is updated by the OS itself with the needed privileges.

Consequently, given how they typically do push out OS updates and
software updates, it doesn't really matter if the update comes with the
OS or with the independent software.

It does matter, and a lot. It's far easier that machines gets OS updates than application updates. The former can be automated, the latter, far less.
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 1:13 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

That is completely irrelevant from the perspective of the software
developer who is hired to write software for such an organization.

There could be "corner case" when you need to deviate from the
standard, sensible approach. I'm not saying you should not be able
to use other encryption libraries in Delphi, but using the OS one is
more often than not the correct approach. Note that some older OS
may not even support latest version of some libraries because they
may be compiled too with compilers that no longer support that
OSes... you may need to compile it yourself, and resolve any issue
arising.

I am not sure what you think is the norm here, but for the sake of
argument, let's assume you are writing something that needs SSL/TLS:

1. If you are developing software for the consumer market, this
software includes a SSL/TLS client, and this client is meant to connect
to arbitrary SSL/TLS servers (e.g. webservices published by someone
other than you or the customer), it might be best to use OS supplied
encryption.

2. If you are developing software that includes both a client
application and a server application, the client(s) will only connect
to your corresponding server, and your server will typically only
accept connections from your client(s), then it is typically best to
use a minimal TLS implementation that is compiled into your software.
It is not a good idea to use OpenSSL or CryptoAPI, because those
implementations contain a lot of complexity you simply don't need for
such projects, and that might only introduce security risks you might
avoid by using a minimal implementation.
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 3:51 PM   in response to: Henrick Hellström in response to: Henrick Hellström
s), then it is typically best to
use a minimal TLS implementation that is compiled into your software.
It is not a good idea to use OpenSSL or CryptoAPI, because those
implementations contain a lot of complexity you simply don't need for
such projects, and that might only introduce security risks you might
avoid by using a minimal implementation.

No, if the 'minimal' implementation is not top quality as well and doesn't come from a good and trustworthy source, and it is not properly kept up to date. When it comes to security the approach is different than for other fields - you want always the latest and the best. Sure, it could have unknown bugs too, but is better than to have known and exploitable ones.
Beware of 'stripping down' security, especially with DIY approaches or 'simplified' implementations, because the risk is something important is missing.
Look at the recent SSLv3 flaw: you can only switch to TLS. If you used a minimal implementation that removed TLS support to reduce 'complexity', you would be in deep troubles...
The only advantage of being compiled into software is you can't use a proxy DLL - if you can install one - to intercept DLL calls. But it means you have to redeploy the application every time a fix is needed. For some kind of apps may be needed, though - but you still need a very good library to link to. And keep some forward paths open...
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 4:55 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

No, if the 'minimal' implementation is not top quality as well and
doesn't come from a good and trustworthy source

Well, then pick one that is top quality and comes from a good and
trustworthy source.

Beware of 'stripping down'
security, especially with DIY approaches or 'simplified'
implementations, because the risk is something important is missing.

That's not what I was talking about. For instance, you could have a TLS
1.2 implementation that only implements the
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 cipher suite, and strips down on
the use of TLS extensions, because you already know exactly which
implementation it should expect to be interacting with. Such an
implementation would be relatively easy to review, analyze and test.
Reviewing complex monsters such as OpenSSL is magnitudes harder, but
those libraries need that complexity for interoperability reasons.
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 12:32 AM   in response to: Henrick Hellström in response to: Henrick Hellström
That's not what I was talking about. For instance, you could have a TLS
1.2 implementation that only implements the
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 cipher suite, and strips down on

And the day someone shows that's insecure or not secure enough, and you have to move to something else? If you have the proper support already it's just a matter of changing conf, in your case you have to modify the library and redeploy the application.

Reviewing complex monsters such as OpenSSL is magnitudes harder, but
those libraries need that complexity for interoperability reasons.

OpenSSL suffeers from code bloat, but not because it implements many protocols. It's more due to its support of many operating systems. That's why they are reducing the number of OS supported.
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 1:30 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

That's not what I was talking about. For instance, you could have a
TLS 1.2 implementation that only implements the
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 cipher suite, and strips down on

And the day someone shows that's insecure or not secure enough, and
you have to move to something else? If you have the proper support
already it's just a matter of changing conf, in your case you have to
modify the library and redeploy the application.

Trust me, the cryptographic building block algorithms are your least
concern. It is extremely rare that an algorithm jumps directly from
being considered completely in line with its theoretical security
bounds, to being broken with a practical exploit. For RC4-128 the
process took over a decade. For MD5 and SHA1 it took years, and
HMAC-MD5 and HMAC-SHA1 are still secure, and we even know pretty well
why they are still secure, due to the HMAC security proofs.

The potential problem is, in practice, with the schemes and protocol
details, and you are stuck with those regardless how many cipher suites
you implement.


Reviewing complex monsters such as OpenSSL is magnitudes harder, but
those libraries need that complexity for interoperability reasons.

OpenSSL suffeers from code bloat, but not because it implements many
protocols. It's more due to its support of many operating systems.
That's why they are reducing the number of OS supported.

I am afraid you are badly mistaken. For instance, the protocol
downgrade exploit has everything to do with the complexity issues
steeming from third party clients implemented to be interoperable with
buggy fourth party servers. The renegotiation exploit really only
become an exploitable problem for clients that do not properly scheck
which server they are talking to, and for servers that allow clients to
login twice over the same connection. Etc.
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 5:11 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

Beware of 'stripping down' security, especially with DIY approaches
or 'simplified' implementations, because the risk is something
important is missing.

I should perhaps add, that when a professional cryptographer designs
such simplified protocols, there are existing methods for logically
proving the security of the protocol. If the implementation is ad hoc
for a single well defined purposes, and done by someone who knows what
he/she is doing, it is in fact more likely to be secure than a generic
solution.
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 12:28 AM   in response to: Henrick Hellström in response to: Henrick Hellström
I should perhaps add, that when a professional cryptographer designs
such simplified protocols, there are existing methods for logically
proving the security of the protocol. If the implementation is ad hoc
for a single well defined purposes, and done by someone who knows what
he/she is doing, it is in fact more likely to be secure than a generic
solution.

Believe me. Unless your an expert - very expert criptographer - stay away from DIY solutions. It's a recipe for disaster.

The mathematical proof of an algorithm may not be easy at all .- and even so, it depends on actual mathematical knowledge, which is not static.

For example if one day someone discovers the mythical function able to generate primes, RSA encryption is in deep troubles.

Anyway even if use a comprehensive library like CryptoAPI or OpenSSL and use a single algorithm - say AES - it's not that it is influenced by all the other code you don't call. It's still only AES and you use just a little part of the library. Do you prefer your simplified version? Could you implement it properly and optimized? Can you test it properly? Little mistakes can lead to huge troubles.
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 1:50 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

Believe me. Unless your an expert - very expert criptographer - stay
away from DIY solutions. It's a recipe for disaster.

I agree, and ftr, I know a thing or two about cryptography myself.

The mathematical proof of an algorithm may not be easy at all .- and
even so, it depends on actual mathematical knowledge, which is not
static.

The cryptographic proofs don't prove the security of algorithms, but of
schemes and protocols. Those proofs do evolve to some extent, but
perhaps not as much as you think. There is indeed a lively debate over
the difference between heuristic proofs in the oracle model and rigid
proofs in the standard model. I know this because papers get published.

For example if one day someone discovers the mythical function able
to generate primes, RSA encryption is in deep troubles.

No. We know how to generate primes. We also know how to factor large
composite numbers, which is what I assume you meant to write. The
problem is that the currently known algorithms are not very efficient
for large enough numbers. If someone were to build a working quantum
computer able to run Shor's algorithm efficiently, we would be in deep
trouble, otherwise it is unlikely that someone would, over night,
discover an efficient factoring algorithm that runs on classical
computers. People have been occupied with the problem for decades, if
not centuries.

Anyway even if use a comprehensive library like CryptoAPI or OpenSSL
and use a single algorithm - say AES - it's not that it is influenced
by all the other code you don't call. It's still only AES and you use
just a little part of the library. Do you prefer your simplified
version? Could you implement it properly and optimized? Can you test
it properly? Little mistakes can lead to huge troubles.

Actually, you are seriously wrong about this. If you have a framework
that allows you to negotiate and pick between multiple cipher suites,
the framework will still perform this negotiation and picking, even if
you in fact only enable a single cipher suite. You still got multiple
alternatives to account for in your testing. The same goes for nearly
all TLS extensions. If there is a bug somewhere in the conditional
framework code that just does negotiation and picking, disabling
alternatives in the configuration will typically not help at all.
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 3:16 AM   in response to: Henrick Hellström in response to: Henrick Hellström
schemes and protocols. Those proofs do evolve to some extent, but
perhaps not as much as you think. There is indeed a lively debate over

Depends. You can prove some algorithms are secure, others that depends on the actual difficulty of handling a given problem

No. We know how to generate primes. We also know how to factor large

No, we don't know how to generate primes. We can calculate some primes, or use approaches that generate something that should be a prime and test if it is. We don't still know how to generate each and every prime easily and quickly... if it becomes possible, factorization becomes much easier. That's way elliptic curve got attention, because they depend on the difficulties of treating a separate mathematical problem. Which one will be "solved" first we don't know - thereby being able to use both ensure you're ready to cope with anything that could happen in the foreseeable future.

discover an efficient factoring algorithm that runs on classical
computers. People have been occupied with the problem for decades, if
not centuries.

It doesn't mean it can't happen - there's a lot of people working on those matters, especially since it became commercially renumerative - maybe tomorrow - who knows? You can't bet security on just one assumption.

Why OTP technologies are still interesting? Because they cannot be broken if the pad is truly random.

Actually, you are seriously wrong about this. If you have a framework
that allows you to negotiate and pick between multiple cipher suites,
the framework will still perform this negotiation and picking, even if

And negotianting the stronger one is usually a sound decision. If new stronger ones are added, and your application can use it automatically, the better. In security "it works, don't touch it" it's usually an approach that leads to troubles...

Anyway, you can disable negotiation if you like.

you in fact only enable a single cipher suite. You still got multiple
alternatives to account for in your testing. The same goes for nearly

So is your idea limiting security so you can limit testing?

all TLS extensions. If there is a bug somewhere in the conditional
framework code that just does negotiation and picking, disabling
alternatives in the configuration will typically not help at all.

Standard libraries are tested by by millions of user, while yours risks to be tested by you only. If there's a bug there are better chances to be spotted and fixed in an OS library than within your application.
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 18, 2014 1:15 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

No. We know how to generate primes. We also know how to factor large

No, we don't know how to generate primes. We can calculate some
primes, or use approaches that generate something that should be a
prime and test if it is. We don't still know how to generate each and
every prime easily and quickly... if it becomes possible,
factorization becomes much easier. That's way elliptic curve got
attention, because they depend on the difficulties of treating a
separate mathematical problem. Which one will be "solved" first we
don't know - thereby being able to use both ensure you 're ready to
cope with anything that could happen in the foreseeable future.

Sorry, but that is pure jibberish. We know for a fact there can't be
any efficient algorithm for generating each 1024 bit prime, simply
because there are too many of them. We do NOT factor large composite
numbers by generating each candidate prime factor and try them out in
order. This would NOT be an efficient algorithm.

http://crypto.stackexchange.com/a/1020/1564
https://primes.utm.edu/howmany.html

discover an efficient factoring algorithm that runs on classical
computers. People have been occupied with the problem for decades,
if not centuries.

It doesn't mean it can't happen - there's a lot of people working on
those matters, especially since it became commercially renumerative -
maybe tomorrow - who knows? You can't bet security on just one
assumption.

Why OTP technologies are still interesting? Because they cannot be
broken if the pad is truly random.

Are OTP technologies still interesting? To whom?

So is your idea limiting security so you can limit testing?

Perhaps you should refresh your knowledge about security proofs. Here
is a starting point:
http://crypto.stackexchange.com/questions/8628/proofs-of-security-methodologies
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 21, 2014 4:27 AM   in response to: Henrick Hellström in response to: Henrick Hellström
Sorry, but that is pure jibberish. We know for a fact there can't be
any efficient algorithm for generating each 1024 bit prime, simply

Now.

order. This would NOT be an efficient algorithm.

There's no need to generate each and every prime. If one day mathematical advances identify how primes are "generated", given a number you can just calculate the prime making it. It's impossible now, but tomorrow? There's a lot of research around this topics, because they are critical to security now.

Are OTP technologies still interesting? To whom?

Those who need an unbreakable cipher without using much tehcnology.

Perhaps you should refresh your knowledge about security proofs. Here
is a starting point:
http://crypto.stackexchange.com/questions/8628/proofs-of-security-methodologies

Because I promised I would refrain from "sniping", I won't answer you.... just it doesn't answer my question: "So is your idea limiting security so you can limit testing?"
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 21, 2014 7:03 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

order. This would NOT be an efficient algorithm.

There's no need to generate each and every prime. If one day
mathematical advances identify how primes are "generated", given a
number you can just calculate the prime making it. It's impossible
now, but tomorrow? There's a lot of research around this topics,
because they are critical to security now.

OK, this got me interested. Are you aware of any actual mathematical
proof that knowing how primes are "generated", would entail an
efficient factoring algorithm? AFAIK the only think we can say, is that
the discovery of an efficient factoring algorithm would entail an
efficient factoring algorithm. You could just as well have asserted
that someone finding the solution to any odd Millenium Prize Problem
might entail an efficient factoring algorithm. Of course anything might
be imagined, but what is there to suggest that finding how primes are
"generated" would lead to a break through in factoring?

Are OTP technologies still interesting? To whom?

Those who need an unbreakable cipher without using much tehcnology.

You need lots of technology and other resources, in order to use an OTP
securely. For starters, completely unbiased hardware random number
generators are not easy to come by. Then you have countless key
management issues to deal with. How do you transfer the OTP? How do you
store it? How do you discard used segments of the key stream and how do
you guarantee that they are permanently destroyed and that the sender
and recipient have synchronized pointers to the next unused segment of
key stream?

Perhaps you should refresh your knowledge about security proofs.
Here is a starting point:
http://crypto.stackexchange.com/questions/8628/proofs-of-security-methodologies

Because I promised I would refrain from "sniping", I won't answer
you.... just it doesn't answer my question: "So is your idea limiting
security so you can limit testing?"

Well, there is nothing in what I have written that would suggest that
my answer is anything but "no", so the real question is why do you ask?
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 21, 2014 2:40 PM   in response to: Henrick Hellström in response to: Henrick Hellström
OK, this got me interested. Are you aware of any actual mathematical
proof that knowing how primes are "generated", would entail an
efficient factoring algorithm? AFAIK the only think we can say, is that

That depends on the "P vs. NP" problem,, the "apparent randomness" of primes - which could be related to the Riemann hypothesis. There are mathematicians who think a proof of the latter could lead to efficient ways to factorize, and quickly if the fisrt answer is "yes".

that someone finding the solution to any odd Millenium Prize Problem

Sure, if someone gets it will win the prize... but have you a proof it can't happen?

You need lots of technology and other resources, in order to use an OTP

You rely too much on technology...

Well, there is nothing in what I have written that would suggest that
my answer is anything but "no", so the real question is why do you ask?

Because you started a long discussion jut to prove your point that self-made encryption is better than relying on tested libraries. Do what you like, you're responsible of the security of your applications. But I prefer by far that Datasnap avoids that approach that is just too risky and a waste of resources - and just more troubles to keep applications updated security-wise.
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 22, 2014 4:56 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

OK, this got me interested. Are you aware of any actual mathematical
proof that knowing how primes are "generated", would entail an
efficient factoring algorithm? AFAIK the only think we can say, is
that

That depends on the "P vs. NP" problem,, the "apparent randomness" of
primes - which could be related to the Riemann hypothesis. There are
mathematicians who think a proof of the latter could lead to
efficient ways to factorize, and quickly if the fisrt answer is "yes".

I am sorry, but this just strikes me as an incoherent stack of concepts
excerpted from some popular science book on the subject.
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 19, 2014 6:27 AM   in response to: Henrick Hellström in response to: Henrick Hellström
Henrick Hellström wrote:

With all of the security hysteria in the media (and that's not
hyperbole) and a little bit here, I was beginning to wonder if all of
my software was constantly on the verge of being compromised (or or
easily compromisable) no matter what I did.

I feel a little better, now.

Thanks for that.

--
Regards,
Bruce McGee
Glooscap Software
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 19, 2014 7:27 AM   in response to: Bruce McGee in response to: Bruce McGee
Bruce McGee wrote:

With all of the security hysteria in the media (and that's not
hyperbole) and a little bit here, I was beginning to wonder if all of
my software was constantly on the verge of being compromised (or or
easily compromisable) no matter what I did.

Well, I do not want to spook you, but it is not completely wrong to
describe SSL/TLS as a protocol always on the verge of being
compromised. TLS is still largely based on the old SSL 3.0
architecture, which pre-dated the modern security proof methodologies.
It is not completely inadequate to describe it as a protocol that is
kept together with duct-tape, and that usually only gets fixed once an
exploit has been discovered.
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 19, 2014 10:27 AM   in response to: Henrick Hellström in response to: Henrick Hellström
Henrick Hellström wrote:

Bruce McGee wrote:

With all of the security hysteria in the media (and that's not
hyperbole) and a little bit here, I was beginning to wonder if all
of my software was constantly on the verge of being compromised (or
or easily compromisable) no matter what I did.

Well, I do not want to spook you, but it is not completely wrong to
describe SSL/TLS as a protocol always on the verge of being
compromised. TLS is still largely based on the old SSL 3.0
architecture, which pre-dated the modern security proof methodologies.
It is not completely inadequate to describe it as a protocol that is
kept together with duct-tape, and that usually only gets fixed once an
exploit has been discovered.

And I'm back to hiding under my bed...

--
Regards,
Bruce McGee
Glooscap Software
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 1:23 PM   in response to: Henrick Hellström in response to: Henrick Hellström
Am 16.10.2014 20:26, schrieb Henrick Hellström:


Consequently, given how they typically do push out OS updates and
software updates, it doesn't really matter if the update comes with the
OS or with the independent software.

Hello,

still one difference (asuming they use WSUS or something like it for
central updates): if it comes with the OS the OS vendor has to care
about creating, testing and deploying the update.

If it comes with your software you have just another issue you need to
have some eye on, namely the crypto library you used.

Greetings

Markus
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 11:17 AM   in response to: Henrick Hellström in response to: Henrick Hellström
you are deploying to an organization that still has Windows XP and IE6

If you're deploy on vendor unsupported software I guess it's up to the software developer targeting such a systems to solve any issue while using old tools as well.

A software development tool can't be kept blocked in some distant past forever and be unable to use actual libraries because someone needs to support EOLed systems Would you like if Delphi won't support new features in iOS8, Android 4.4 and Windows 10 because someone needs to deploy on iOS2, Android 1 and Win 2000?

IE6 will now die even faster because SSLv3 support will be removed due to the vulnerability disclosed yesterday. Most sites are removing support.
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 12:03 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

If you're deploy on vendor unsupported software I guess it's up to
the software developer targeting such a systems to solve any issue
while using old tools as well.

I think you might approach this the wrong way. While Embt only
officially supported the Windows XP target up to Delphi XE5, that is
largely beside the point. The point is that you can't blindly assume
that your customer relies on OS security for all security and that it
always is easier to rely on the OS vendor to push updates
automatically, than for you to provide independent updates for your own
software.
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 12:28 PM   in response to: Henrick Hellström in response to: Henrick Hellström
largely beside the point. The point is that you can't blindly assume
that your customer relies on OS security for all security and that it
always is easier to rely on the OS vendor to push updates
automatically, than for you to provide independent updates for your own
software.

You can't blindly assume anything, but explain me how could be easier for a company to push its own updates than the OS vendor...

Today I received all the Windows OS and applications updates through our company WSUS server. What I didn't receive are the Java updates, the Adobe updates, the OpenSSL updates...
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 1:24 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

Today I received all the Windows OS and applications updates through
our company WSUS server. What I didn't receive are the Java updates,
the Adobe updates, the OpenSSL updates...

...and I have worked with organizations where the IT staff deploys all
software updates remotely, except to power users that are allowed to
install software on their own. I guess such IT policies come in all
flavors.
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 1:25 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Am 16.10.2014 21:28, schrieb Luigi Sandon:
largely beside the point. The point is that you can't blindly assume
that your customer relies on OS security for all security and that it
always is easier to rely on the OS vendor to push updates
automatically, than for you to provide independent updates for your own
software.

You can't blindly assume anything, but explain me how could be easier for a company to push its own updates than the OS vendor...

Today I received all the Windows OS and applications updates through our company WSUS server. What I didn't receive are the Java updates, the Adobe updates, the OpenSSL updates...

Hello,

but it would be possible to get those updates via WSUS as well. Our IT
started to do just that a few weeks ago.

Greetings

Markus
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 3:38 PM   in response to: Markus Humm in response to: Markus Humm
but it would be possible to get those updates via WSUS as well. Our IT
started to do just that a few weeks ago.

Yes, with WSUS you can deploy other software as well. But it's up to you. Also, you need an updated package to deploy. How many here use OpenSSL and offer an update package every time OpenSSL release a new version?

Moreover it works only for WSUS - Windows Update for consumer users won't deliver but MS updates.

If yours is an internl application and your IT fully manage WSUS, you can update whatever you like. If you application is for external customers, you may reccomend them best practices, but then is up to you. Just to put the blame on you if your application is not updated ;)
Enquiring Mind

Posts: 88
Registered: 10/6/08
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 6:54 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

Some algorithms have known back-doors, others do not.

You can always implement a known algorithm in a given product in a way to allow a backdoor or lower its security - and you can discover it only reverse engineering it fully.

I tend to disagree. If one considers the AES algorithm, for example, it is purely a mathematical transformation of numerical data. There would be no point in reverse engineering the code to discover the algorithm because the algorithm is clearly defined in the NSA specification. The only possible point in reverse engineering the code would be to identify programming errors. Moreover no strong encryption algorithm should rely on any data encapsulated in the code file. Any constants used in the AES algorithm are clearly indicated in the specification - so no secret there, either. The point is that the algorithm depends not on any secret information buried in the algorithm code file, but on the mathematical intractability of finding the inverse of a complex mathematical function. The only trapdoor that could possible exist is a fundamental weakness in the mathematical formulation that nobody has succeeded in discovering thus far.

If Delphi were to use the Windows CryptoAPI for message encryption, that would build in yet another unnecessary system dependency that would hinder platform independence.

It could wrap different libraries with a unified internal API, as it already does for other libraries.

If at the message sending end of the communication we are on a Windows machine, so that message is encrypted with CryptoAPI, and at the receiving end we are on a different platform, which uses some different encryption/decryption implementation, there is the probability of the decryption code being not 100% compatible with the encryption code. That would be a disaster! The only way of avoiding this scenario is to use the same library at each end, albeit compiled into code of the respective platforms.

Cryptographic belongs to the realm of application code, not system code,

No - this is a big mistake. Security needs to be always up-to-date, or it may become vulnerable - unless you can ensure you keep your application code up-to-date.

I think that you may be confusing say virus protection security software, which depends on having an up-to-date database of known viruses and threats, and encryption software, which should ideally not change in time (other than to correct errors and adapt to revisions in the operating system), otherwise files encrypted a long time ago could cease to be decryptable if significant changes to the mathematical algorithm at the basis of the encryption/decryption code were to intervene.

IMHO. Hence a cryptographic library in Pascal that can be compiled into the code of any target platform is the right way to go.

That would mean that someone with the righ skill needs to maintain it. Especially since Delphi maintanins barely the last release for six month, if it had its own implemented libary there's a real risk they get outdated and vulnerable very soon. Sure, it could become another marketing trick to sell new versions, but it's something I wouldn't like to be bound to. That's a worst dependency than being bound to OS libraries...

You know, because encryption algorithms are really just a bit of numerical programming, which is not dependent on strings, system calls, and the like, you could write the Pascal code in Turbo Pascal or Delphi 1 and the code would be still be compilable today. It's only system-dependent and third party library dependent code that rapidly becomes obsolete.

As for the skill levels needed to maintain and further develop cryptographic software, I would have more confidence in a company that is specialised in just that area, than in a company like Microsoft who main line of business is operating systems and office software. Who knows much effort they put into maintaining cryptographic software, seen perhaps as a sideline.

EM
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 7:23 AM   in response to: Enquiring Mind in response to: Enquiring Mind
Enquiring Mind wrote:

I think that you may be confusing say virus protection security
software, which depends on having an up-to-date database of known
viruses and threats, and encryption software, which should ideally
not change in time (other than to correct errors and adapt to
revisions in the operating system), otherwise files encrypted a long
time ago could cease to be decryptable if significant changes to the
mathematical algorithm at the basis of the encryption/decryption code
were to intervene.

Indeed, and it should be noted that the overwhelming majority of
vulnerabilities of attacks against SSL/TLS implementations, are not
really pure cryptographic attacks, but vulnerabilities caused
over-complexity in the non-cryptographic parts of the systems.

For instance, you wouldn't need to protect yourself from BEAST or
POODLE, if it wasn't for browsers running third party java script over
HTTPS connections that are also used for transferring other data. You
wouldn't need a Fallback Signalling Cipher Suite Value, if it wasn't
for client software trying to circumvent bugs in completely unrelated
server software. Etc.
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 21, 2014 4:17 AM   in response to: Henrick Hellström in response to: Henrick Hellström
vulnerabilities of attacks against SSL/TLS implementations, are not
really pure cryptographic attacks, but vulnerabilities caused
over-complexity in the non-cryptographic parts of the systems.

There are implementation bugs and cryuptographic attacks. You find them both.

For instance, you wouldn't need to protect yourself from BEAST or
POODLE, if it wasn't for browsers running third party java script over

Sure, if you don't do anything over the web you don't need to protect much :)

And sure, the whole HTTP + HTML + Javascript is a huge mess for remoting createad by companies more interested in "steal" your data than security, but it looks that too many people use that.
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 21, 2014 7:57 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

Sure, if you don't do anything over the web you don't need to protect
much :)

This discussion is about transport security for DataSnap. SSL/TLS
contains a lot of complexity, exactly because it is used for a wide
variety of applications, each of various respective complexity. This is
however an argument against using stock implementations of SSL/TLS
for DataSnap. For instance, it would, in retrospect, be more secure to
let DataSnap send heartbeat messages as part of the DataSnap protocol
(wrapped as TLS application data), instead of as TLS heartbleed
messages.
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 21, 2014 2:16 PM   in response to: Henrick Hellström in response to: Henrick Hellström
This discussion is about transport security for DataSnap. SSL/TLS
contains a lot of complexity, exactly because it is used for a wide
variety of applications, each of various respective complexity. This is

Datasnap too should be able to handle a wide variety of application. And it doesn't need encryption only, as I pointed out.

however an argument against using stock implementations of SSL/TLS

Yes, use your own one without any audit by experts and pray you didn't introduce more bugs than in stock ones. Unless you're writing a very specific application with such a requirement, why should you spend a lot of efforts in rewriting and testing? Just because you're scared by libraries everybody uses? It's the "not developed here" issue?

Sure, if I have to write a military-grade application I could start with a clean-room implementation - just you need the funding, the personnel, the expertise, the QA...

for DataSnap. For instance, it would, in retrospect, be more secure to
let DataSnap send heartbeat messages as part of the DataSnap protocol
(wrapped as TLS application data), instead of as TLS heartbleed
messages.

Which is not forbidden even if you use a stock TLS implementation - Datasnap can still use its own protocol and use TLS just for protecting the channel.

Anyway Heartbleed was just a big bug in the heartbeat implementation existing in OpenSSL only - not a TLS one. Exactly the kind of bug - a missing check - you risk to introduce if you reinvent the wheel without really good reasons.

Sure, if you can hire a squad of expert developers able to rewrite and maintain the parts of CryptoAPI or OpenSSL you need and enough time, do it. Can you? How many Delphi developers can? Even Embarcadero can't without a not so small investment in people and time. And with what advantages? Less audited and tested code?
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 11:31 AM   in response to: Enquiring Mind in response to: Enquiring Mind
I tend to disagree. If one considers the AES algorithm, for example, it is purely a mathematical transformation of numerical data. There would be no point in reverse engineering the code to discover the algorithm because the algorithm is clearly defined in the NSA specification.

Do you believe I could not implement it in a slightly different way? Or have something trigger a different code path in some given situations? Nobody ensure you that I implemented AES exactly the way it should, unless somebody reverse my implementation and checks I did what I should have done :)

If at the message sending end of the communication we are on a Windows machine, so that message is encrypted with CryptoAPI, and at the receiving end we are on a different platform, which uses some different encryption/decryption implementation, there is the probability of the decryption code being not 100% compatible with the encryption code.

Wrong. As you said, the algorithms are standard. Compliant implementations works flawlessly against each other. Do you have issue using IE to talk to a Linux server? Firefox or Chrome to an IIS server?

That would be a disaster! The only way of avoiding this scenario is to use the same library at each end, albeit compiled into code of the respective platforms.

The whole encrypted Internet wouldn't work if so. It would depend on a single library instead of standards :)

otherwise files encrypted a long time ago could cease to be decryptable if significant changes to the mathematical algorithm at the basis of the encryption/decryption code were to intervene.

Bugs gets fixed, new algorithms and standards are added.... take Heartbleed, it is a bug in OpenSSL implementation. Nothing changes in the mathematical algorithm, but you need to deploy an updated library or your data are at risk. In Linux OpenSSL is updated automatically, in Windows it is not. You have to update each application that uses its private copy of OpenSSL. Perform a search on your disk, and check how many OpenSSL DLLs you have. And still you may have application statically bound to OpenSSL that may contain the buggy code...

As for the skill levels needed to maintain and further develop cryptographic software, I would have more confidence in a company that is specialised in just that area, than in a company like Microsoft who main line of business is operating systems and office software.

Which company are specialized in that area? RSA, maybe, and a few others.

Who knows much effort they put into maintaining cryptographic software, seen perhaps as a sideline.

I guess there are more cryptography experts at MS, than at Embarcadero or working on Lockbox :) Also MS could license its code from a company like RSA or the like - it would be surely a good option. Microsoft is not regarding security as a sideline - it burnt its butt already enough, and is doing a lot of efforts to make its software far secure and robust. I would not complain if Embarcadero license libraries from a company with a good reputation, I'm more worried if it uses some small free times efforts to save money....
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 12:32 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

I guess there are more cryptography experts at MS,

Numbers isn't everything. You typically only need many developers if
the project is complex enough. Security flaws are typically caused by
regression bugs caused by complexity, rather than stupid mistakes a
single developer might do.

Hence, from a security perspective, a project with one developer and
100 testers, is more likely to be secure, than a project with 100
developers and 10000 testers.
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 12:16 AM   in response to: Henrick Hellström in response to: Henrick Hellström
regression bugs caused by complexity, rather than stupid mistakes a
single developer might do.

Heartbleed is a stupid mistake of a single developer. The SSLv3 flaw is due two issues in how the CBC block cipher and RC4 stream cipher are designed. Algorithms regarded secure may contain design flaws discovered just later, or simply new kinds of attacks become possible because mathematical techniques improve and processing power as well.

As soon as a technique that allows to break security in a resonable time is discovered, it may be the design itself, not a poor implementation, a poor implementation could be usually fixed (Heartbleed), design flaws can't (SSLv3) - all you can do is to switch to a newer, more secure technology.

For example rainbow tables allows now to easily attack hashes of relatively short passwords. If you just hash once, and don't use a proper salt, hashes can be "reversed". It's not a "regression bug caused by complexity" - it's simply that computing power now allows generating large rainbow tables, and quick lookups, and allows a different attack against hashes than those available a few years ago. You can defend making your implementation more complex (salt, multiple hashes, longer passwords, etc.) - a naive one is vulnerable - to make the attacker job harder.

Hence, from a security perspective, a project with one developer and
100 testers, is more likely to be secure, than a project with 100
developers and 10000 testers.

It's not that simple.
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 1:55 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

The SSLv3 flaw is due two issues in how the CBC block cipher and RC4
stream cipher are designed.

Not at all, it is due to the MAC-then-Encrypt scheme not being IND-CCA2
in the standard model. This has been known at the theoretical level for
at least a decade and a half. The only thing new about the POODLE
attack, was that someone managed to turn this theoretically well-known
weakness into a practical exploit.
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 21, 2014 4:14 AM   in response to: Henrick Hellström in response to: Henrick Hellström
Not at all, it is due to the MAC-then-Encrypt scheme not being IND-CCA2

Which is exactly what I said.

https://www.openssl.org/~bodo/ssl-poodle.pdf
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 21, 2014 8:00 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

Not at all, it is due to the MAC-then-Encrypt scheme not being
IND-CCA2

Which is exactly what I said.

https://www.openssl.org/~bodo/ssl-poodle.pdf

Uhm, no, this is what you wrote:

The SSLv3 flaw is due two issues in how the CBC block cipher and RC4
stream cipher are designed

The CBC block cipher is designed just fine. The problem is in the SSLv3
record layer, not in CBC or the block cipher.
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 21, 2014 2:02 PM   in response to: Henrick Hellström in response to: Henrick Hellström
The CBC block cipher is designed just fine. The problem is in the SSLv3
record layer, not in CBC or the block cipher.

It's how CBC is designed to work in SSLv3: "We show here how to put together an effective attack against CBC encryption as used by SSL 3.0" - which is not a "broken implementation" of CBC - because CBC doesn't mandate a different use - it's just "best practice" that should be used to make it safer.

And it well shows how "little details" can compromise security - CBC itself has known issues if not used very carefully (i.e. IV generation) - and that's a good reason to avoid to reinvent the wheel and/or take shortcuts in security. And because there's no workarounds, if you just implemented in your app SSLv3, you would be in the need to update the application - not just disable the flawed protocol - hoping you have already implemented the newer protocols and don't need to start from scratch.... or use your OS libraries or other good ones that already provide what you need.
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 21, 2014 6:29 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

The CBC block cipher is designed just fine. The problem is in the
SSLv3 record layer, not in CBC or the block cipher.

It's how CBC is designed to work in SSLv3: "We show here how to put
together an effective attack against CBC encryption as used by SSL
3.0" - which is not a "broken implementation" of CBC - because CBC
doesn't mandate a different use - it's just "best practice" that
should be used to make it safer.

You misinterpret and misrepresent matters.

Firstly, CBC is standardized by
http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. SSLv3
does in fact deviate from this standard (Appendix C to be more
precise), which is why the BEAST attack is possible. This is however a
design flaw SSLv3.0 shares with TLSv1.0 (but not TLSv1.1 and higher).
TLSv1.0 is not vulnerable to POODLE. And except from this, there is no
problem with "how CBC is designed to work in SSLv3". SSLv3 uses CBC
mode just fine, in perfect keeping with the standard
http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf#17.

Secondly, the problem is with the underspecification of the
GenericBlockCipher struct that is part of the SSLv3 record layer
protocol. It just says:

padding
Padding that is added to force the length of the plaintext to be
a multiple of the block cipher's block length.

which in TLS 1.0 (paragraph 6.2.3.2) was strengthened to:

padding
Padding that is added to force the length of the plaintext to be
an integral multiple of the block cipher's block length. The
padding may be any length up to 255 bytes long, as long as it
results in the TLSCiphertext.length being an integral multiple of
the block length. Lengths longer than necessary might be
desirable to frustrate attacks on a protocol based on analysis of
the lengths of exchanged messages. Each uint8 in the padding data
vector must be filled with the padding length value.

POODLE exploits that (some) SSLv3 implementations don't check that the
padding data vector is filled with the padding length value. This has
nothing to do with how CBC is designed to work. It has everything to do
with how the padding that is appended to the plain text, is processed
by the record layer.
Enquiring Mind

Posts: 88
Registered: 10/6/08
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 7:10 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:
I tend to disagree. If one considers the AES algorithm, for example, it is purely a mathematical transformation of numerical data. There would be no point in reverse engineering the code to discover the algorithm because the algorithm is clearly defined in the NSA specification.

Do you believe I could not implement it in a slightly different way? Or have something trigger a different code path in some given situations? Nobody ensure you that I implemented AES exactly the way it should, unless somebody reverse my implementation and checks I did what I should have done :)
Given mathematical encryption/decryption algorithm, there's an infinite number of possible code implementations, of which a significantly large subset may be acceptably error-free. It would be more profitable to check that a given implementation produces the right results for a given suite of test cases than to attempt to decompile the code and then seek to identify flaws in the implementation. The NSA documentation provides several test cases of corresponding input and output data that may be used to check an implementation. But in the light of Dijkstra's dictum "Testing shows the presence, not the absence of bugs", it's as well to broaden the range of test cases to include boundary cases and furthermore perform a sufficiently large number of encryption-decryption cycles on randomly generated cleartext cases to be able to deduce on a probabilistic basis that the probability of there being residual undetected errors in the implementation is acceptably small. Occurrences of these errors in practice represent extreme tail situations having a level of probability comparable to probabilities of failure commonly accepted in other branches of science and technology, often as a function of the consequential cost of failure.

If at the message sending end of the communication we are on a Windows machine, so that message is encrypted with CryptoAPI, and at the receiving end we are on a different platform, which uses some different encryption/decryption implementation, there is the probability of the decryption code being not 100% compatible with the encryption code.

Wrong. As you said, the algorithms are standard. Compliant implementations works flawlessly against each other. Do you have issue using IE to talk to a Linux server? Firefox or Chrome to an IIS server?
You have a valid point but I was not referring to communications using third party frameworks. I was referring to client server communications where the client and server modules are the responsibility of the same organisation. It is safer for the two communicating modules to do their own encryption and decryption rather than rely on network security systems that could be vulnerable to interception attacks on the clear message.

That would be a disaster! The only way of avoiding this scenario is to use the same library at each end, albeit compiled into code of the respective platforms.

The whole encrypted Internet wouldn't work if so. It would depend on a single library instead of standards :)
But it would work for integrated client-server software applications from the same software developer.

otherwise files encrypted a long time ago could cease to be decryptable if significant changes to the mathematical algorithm at the basis of the encryption/decryption code were to intervene.

Bugs gets fixed, new algorithms and standards are added.... take Heartbleed, it is a bug in OpenSSL implementation. Nothing changes in the mathematical algorithm, but you need to deploy an updated library or your data are at risk. In Linux OpenSSL is updated automatically, in Windows it is not. You have to update each application that uses its private copy of OpenSSL. Perform a search on your disk, and check how many OpenSSL DLLs you have. And still you may have application statically bound to OpenSSL that may contain the buggy code...
Thank you for mentioning that bug. It's a good example of the perils of relying on third party DLL's and of a situation where using a proprietary encryption-decryption algorithm upstream and downstream could reduce one's vulnerability.

As for the skill levels needed to maintain and further develop cryptographic software, I would have more confidence in a company that is specialised in just that area, than in a company like Microsoft who main line of business is operating systems and office software.

Which company are specialized in that area? RSA, maybe, and a few others.

Who knows much effort they put into maintaining cryptographic software, seen perhaps as a sideline.

I guess there are more cryptography experts at MS, than at Embarcadero or working on Lockbox :) Also MS could license its code from a company like RSA or the like - it would be surely a good option. Microsoft is not regarding security as a sideline - it burnt its butt already enough, and is doing a lot of efforts to make its software far secure and robust. I would not complain if Embarcadero license libraries from a company with a good reputation, I'm more worried if it uses some small free times efforts to save money....

By the way many thanks to you and Henrick Hellström for sharing your in-depth knowledge about security in his thread, much of it outside my own area of expertise.

EM
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 21, 2014 4:11 AM   in response to: Enquiring Mind in response to: Enquiring Mind
Given mathematical encryption/decryption algorithm, there's an infinite number of possible code implementations, of which a significantly large subset may be acceptably error-free.

Usually it's the other way. There are few ways to make it correctly, and many to screw it up.

It is safer for the two communicating modules to do their own encryption and decryption rather than rely on network security systems that could be vulnerable to interception attacks on the clear message.

The network security systems use the same encryption you would use. They could be vulnerable as much as your application. All depends if you need end-to-end encryption or not - but you use the same techniques. Developing your own, unless your have a team of expert cryptographers, would just mean less security, nor more. And interoperabilty among library is not optional.

But it would work for integrated client-server software applications from the same software developer.

But why would you strongly tie your application to a single library? It will just mask out interoperaility issue and wrong implementations. It may look to work, but it could work the wrong way.

Thank you for mentioning that bug. It's a good example of the perils of relying on third party DLL's and of a situation where using a proprietary encryption-decryption algorithm upstream and downstream could reduce one's vulnerability.

It wasn't the algorithm. It was the implementation. Exactly the kind of bugs you risk in your proprietary one and noone will notice unlike in more used libraries. "Security by oscurity" is not good security.
Arnaud BOUCHEZ

Posts: 143
Registered: 2/17/02
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 14, 2014 9:55 AM   in response to: Luigi Sandon in response to: Luigi Sandon
http://blog.synopse.info/tag/security

For an open source n-tier framework implementing security since the ground up. Several security pattern, to be exact.
And using it for both remote ORM and SOA features.
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 15, 2014 6:57 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

Someone asked this thread so let's start.

I'm glad you are taking it seriously.

Both Datasnap (unless your rely on the old DCOM version, or rely on a
web server - which may mean more expensive licensing) and
AppTethering lack proper security features - from proper encryption
of transmitted data, to proper authentication/authorization
techniques. (for my analysis of Datasnap see
http://www.sandon.it/?q=node/57, written in 2010 but still actual
because little changed since then),

Some things have changed.

For example, Delphi supports HTTPS in stand alone REST servers as of
XE2. No IIS required. Support for Apache modules was added (re-added)
in XE6. This lets you host a web server on any version of Windows and
(I hope) means that Linux server support isn't far away. Good news for
a bunch of reasons, including licensing costs.

Your QC asking for proxy support was also implemented in XE2.

http://qc.embarcadero.com/wc/qcmain.aspx?d=85467

I'll agree that I'd like to see some security built in to App
Tethering, though.

Delphi still supports web services, but the latest (but not
recent...) standards like WS Security were AFAIK never implemented.

ws-* features don't seem to supported yet.

http://qc.embarcadero.com/wc/qcmain.aspx?d=104755

However, HTTPS support was added to web service server applications in
XE2.

Would you rely on them to transmit your customers' sensitive data?
Could an expensive development tool deliver so little today from a
security point of view, especially now data breaches can be very
costly both in monetary and reputation terms?

Seems a little argumentative.

I won't disagree with the implications of security breaches, but I'm
fairly comfortable with the SSL features for my needs.

Why Delphi doesn't offer a good cryptographic library, preferably
wrapping CryptoAPI on Windows (because this way fixes and updates are
automatically delivered, nor complex alorithms need to be
reimplemented from scratch) and OpenSSL or the like on other systems?
And why then don't build on it proper security into its frameworks?

As Nick mentioned - restrictions on encryption software. You mention
that these have been relaxed, but they're still present and non-trivial.

And then there is this from the Indy guys. Maybe Remy can shed some
light on some of the specific problems or whether they consider it to
be convoluted enough that they just choose to side step the issue
altogether.

http://www.indyproject.org/sockets/ssl.en.aspx

I had heard about export restrictions, but until recently, I didn't
realise that import restrictions were a problem, too.

Wrapping the Windows library sounds interesting, but I'd be worried
about consistency with other libraries and the consequences of shoddy
Windows update practices. You suggested OpenSSL on other platforms. How
about using this everywhere?

Should Embarcadero assign more resources
to ensure Delphi applications can stand a real scrutiny from a
security perspective? Do you feel you need them, or do you believe
you can do without? Or do you just use third party frameworks, and
Delphi should just dump its ones and save resources to develop
something else?

I absolutely think Embarcadero should dedicate more resources to
security. I don't need security everywhere, but in the places where it
matters, it matters a lot.

Of course "do more security" is a little broad. What are some specific,
realistic, actionable things that can be quantified in (several) bug
reports or feature requests?

--
Regards,
Bruce McGee
Glooscap Software
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 16, 2014 2:11 AM   in response to: Bruce McGee in response to: Bruce McGee
For example, Delphi supports HTTPS in stand alone REST servers as of
XE2. No IIS required.

As said, HTTPS requires a PKI infrastructure in place. As long as you just need server authentication, it could be easy enough - just buy a certificate (self-signed ones are not secure).

It's when you need client authentication and authorization that it becomes far more complex. It means you have to obtain a CA to issue certificate for each client, and manage them (i.e. replace them when they expire, revoke them, etc. etc.). Some services do need this level of protection - you need only authorized clients to connect, and plain passwords are not secure enough, or you may have application that run as services and you wish to avoid to store password somewhere to let them access other services - you may want to use the credentials they have already, and which are managed centrally.

Support for Apache modules was added (re-added)

But it means more support costs. Apache doesn't get updated automatically on your server, and since Apache project no longer have Windows installers, it becomes a manual upgrade process. A web server also means a larger attack surface, and the need to configure it properly for a given application disabling whatever you don't need, otherwsise by default it can use too many resources. It can be an overly broad solution for some class of applications that do need a remote solution, but don't need to serve a large number of clients outside a firewall. There are reasons to use a remoting solution wihout a web server and HTTP transport.

Your QC asking for proxy support was also implemented in XE2.

Hope it also supports NTLM proxy authentication using the process credentials.

I'll agree that I'd like to see some security built in to App
Tethering, though.

Good.

ws-* features don't seem to supported yet.

And that's another issue when you have to work with services that do require it. Nor you can offer it to offer services to compliant applications.

However, HTTPS support was added to web service server applications in
XE2.

But this is not an end-to-end solution. Data protections ends at the web server level. You have the same issue with Datasnap. The web server does security for you, but it stops at it. If you want to make two datasnap application talk to each other, or both work behind a web server, or data protection becomes an issue.

Seems a little argumentative.

I was just trying to understand why there's so little consideration of security from Embarcadero while security breaches gets more widespread, get news coverage, and cost money and reputation to companies. I mean, it's not today some obscure requirement for some very specific military application. We have more and more data travelling across networks, and there are more and more ways to capture them and use them in illegal ways.

I won't disagree with the implications of security breaches, but I'm
fairly comfortable with the SSL features for my needs.

I understand some needs are covered, but others are not.

As Nick mentioned - restrictions on encryption software. You mention
that these have been relaxed, but they're still present and non-trivial.

Everybody else have encryption - so it's not this the real reason - unless the real owner of Embarcadero is the NSA...

Anyway even if Datasnap didn't come with the algorithms, it could have come with the proper hooks to add them. Unluckily, the "filter" design is not good for that, because it lacks the handshake needed to establish a session key securely, for example.

And then there is this from the Indy guys. Maybe Remy can shed some

Which do offer the encryption Delphi don't through OpenSSL - despite all OpenSSL issues.

I had heard about export restrictions, but until recently, I didn't
realise that import restrictions were a problem, too.

With all the time Embarcadero spends in changing the license to add stupid conditions (oh well, they were trying even to forbid to use Delphi abroad! Export restrictions?), it could have someone read http://www.bis.doc.gov/index.php/policy-guidance/encryption/

Because it looks everybody else is compliant with exporting, but Embarcadero. Anyway if a Delphi distributions contains OpenSSL, it does contain and export encryption libraries...

Wrapping the Windows library sounds interesting, but I'd be worried
about consistency with other libraries and the consequences of shoddy
Windows update practices. You suggested OpenSSL on other platforms. How
about using this everywhere?

Shoddy windows update practices? I'm more worried about OpenSSL. Check your systems for how many different versions of OpenSSL DLLs you may have installed - and which versions!

OpenSSL doesn't get update with Windows - it's your responsibility to update it every time an issue is discovered (last one, yesterday). It means you have to issue an update of your application everytime OpenSSL release a fix.

CryptoAPI are also far better integrated with the system, for example certificate stores, so you don't have to keep your certificate, certificate chains, and keys in files around (or write them in the registry..), nor handle CA and the like yourself - and certificates stores can be managed from Active Directory.

While OpenSSL is now focussing on Linux as the primary platrorm after the huge code problems that arose, and Windows will become a secondary one.

Also, ff Delphi used CryptoAPI, it would automatically use the latest version delivered with Windows. And if export restrictions are an issue for Embarcadero, just wrapping Windows API would solve the problem, wouldn't it?

I absolutely think Embarcadero should dedicate more resources to
security. I don't need security everywhere, but in the places where it
matters, it matters a lot.

Oh well, on something we do agree.

Of course "do more security" is a little broad. What are some specific,
realistic, actionable things that can be quantified in (several) bug
reports or feature requests?

Embarcadero knows already.
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 17, 2014 1:47 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

For example, Delphi supports HTTPS in stand alone REST servers as of
XE2. No IIS required.

As said, HTTPS requires a PKI infrastructure in place. As long as you
just need server authentication, it could be easy enough - just buy a
certificate (self-signed ones are not secure).

It does almost everything I need, which is why I was really happy to
see this feature. I have more stand alone application servers than ones
hosted by IIS.

Self signed certificates seem to be fine for encryption. Don't worry, I
can't imagine using one for a public facing service.

It's when you need client authentication and authorization that it
becomes far more complex. It means you have to obtain a CA to issue
certificate for each client, and manage them (i.e. replace them when
they expire, revoke them, etc. etc.). Some services do need this
level of protection - you need only authorized clients to connect,
and plain passwords are not secure enough, or you may have
application that run as services and you wish to avoid to store
password somewhere to let them access other service s - you may want
to use the credentials they have already, and which are managed
centrally.

Client certificates seem complicated. And expensive. I don't think I
know anyone who uses them.

As I think about it, I wonder if you can use self signed certificates
on the client side? It's only that initial connection that's
susceptible to MITM attacks, right?

Still can't see myself juggling client certificates, but it's an
interesting question.

Support for Apache modules was added (re-added)

But it means more support costs.

It's one option. And a good one.

Even without my Linux wish list item, I like that it doesn't tie me to
a specific version or edition of Windows. In this way, IIS vs Apache
reminds me of Internet Explorer vs pretty much every other browser.

Your point that apache isn't updated automatically is valid, but I
don't know how much of a burden it would be. Aren't most patches
reviewed before adding them to a production server? This wouldn't be
much different. I stopped letting Windows apply its own patches
automatically years ago. Mostly because of rebooting issues.

Your QC asking for proxy support was also implemented in XE2.

Hope it also supports NTLM proxy authentication using the process
credentials.

I don't know. It wasn't in the QC report.

How important is this, objectively, and does a QC report exist?

I'll agree that I'd like to see some security built in to App
Tethering, though.

Good.

ws-* features don't seem to supported yet.

And that's another issue when you have to work with services that do
require it. Nor you can offer it to offer services to compliant
applications.

I think I read that there are third party solutions, but this is one of
the cases where I strongly believe the functionality should be
available out of the box.

I'll post the QC again and hope some more people vote for it.

http://qc.embarcadero.com/wc/qcmain.aspx?d=104755

However, HTTPS support was added to web service server applications
in XE2.

But this is not an end-to-end solution. Data protections ends at the
web server level. You have the same issue with Datasnap. The web
server does security for you, but it stops at it. If you want to make
two datasnap application talk to each other, or both work behind a
web server, or data protection becomes an issue.

I don't understand how this is a problem.

Communication between two DataSnap servers or between a DataSnap server
and some outside service can be encrypted or not as required.

What am I missing?

I won't disagree with the implications of security breaches, but I'm
fairly comfortable with the SSL features for my needs.

I understand some needs are covered, but others are not.

I think the vast majority of them are.

I can't back it up with numbers, but I have the feeling that HTTP is
being used more than dedicated TCP/IP connections.

As Nick mentioned - restrictions on encryption software. You mention
that these have been relaxed, but they're still present and
non-trivial.

Everybody else have encryption - so it's not this the real reason -
unless the real owner of Embarcadero is the NSA...

There are still restrictions.

Anyway even if Datasnap didn't come with the algorithms, it could
have come with the proper hooks to add them. Unluckily, the "filter"
design is not good for that, because it lacks the handshake needed to
establish a session key securely, for example.

Agreed.

And then there is this from the Indy guys. Maybe Remy can shed some

Which do offer the encryption Delphi don't through OpenSSL - despite
all OpenSSL issues.

There are two separate things here.

First, Indy doesn't ship the OpenSSL libraries. You have to download
them separately because of restrictions. That's the point I was making.
I'd be curious to know if they can cite specific reasons or if they
just decided that this is a much simpler solution.

If you're saying that OpenSSL is unsuitable for security purposes, then
that's a whole other discussion.

I had heard about export restrictions, but until recently, I didn't
realise that import restrictions were a problem, too.

With all the time Embarcadero spends in changing the license to add
stupid conditions (oh well, they were trying even to forbid to use
Delphi abroad! Export restrictions?), it could have someone read
http://www.bis.doc.gov/index.php/policy-guidance/encryption/

Remember the sniping thing.

Because it looks everybody else is compliant with exporting, but
Embarcadero. Anyway if a Delphi distributions contains OpenSSL, it
does contain and export encryption libraries...

Not everyone. At least some either wrap a third party (like OpenSSL or
CryptoAPI) or leave it to the user to download libraries separately.

Python and PHP (I think), for example.

If Embarcadero has extra time on their hands, I have a whole wish list
of things I would like them to tackle before shipping their own
encryption library.

I'd much rather see a comprehensive wrapper around OpenSSL.

Wrapping the Windows library sounds interesting, but I'd be worried
about consistency with other libraries and the consequences of
shoddy Windows update practices. You suggested OpenSSL on other
platforms. How about using this everywhere?

Shoddy windows update practices? I'm more worried about OpenSSL.
Check your systems for how many different versions of OpenSSL DLLs
you may have installed - and which versions!

I keep the ones my applications use reasonably up to date.

OpenSSL doesn't get update with Windows - it's your responsibility to
update it every time an issue is discovered (last one, yesterday). It
means you have to issue an update of your application everytime
OpenSSL release a fix.

Unless there's an emergency, I just make sure the next update of my
software includes the latest version.

For example, 1.0.1j will be included with my next updates.

CryptoAPI

CryptoAPI is Windows centric, which excludes Mac, iOS and Android.

Someone else pointed out that there are still a lot of XP users out
there who won't get updates. And I would be embarrassed to tell you
when the last update was performed on a Windows 7 machine that I used
recently.

The more I think about it, I would prefer that Embarcadero not wrap a
Windows specific library. Or at least not only a Windows library.

I see that you opened a QC report for this. Nice.

http://qc.embarcadero.com/wc/qcmain.aspx?d=128340

I absolutely think Embarcadero should dedicate more resources to
security. I don't need security everywhere, but in the places where
it matters, it matters a lot.

Oh well, on something we do agree.

Of course. That's the point of having a rational discussion. To shake
out legitimate points of agreement and disagreement.

Of course "do more security" is a little broad. What are some
specific, realistic, actionable things that can be quantified in
(several) bug reports or feature requests?

Embarcadero knows already.

You can do better than that.

Anyone can make a broad, non specific request, but you say that you
have significant real world experience with security, so you're in a
better position than someone like me to add context and specifics.

And that means fewer torches and pitchforks (I know, hyperbole, but let
me have this one) and more time in QC.

--
Regards,
Bruce McGee
Glooscap Software
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 21, 2014 1:01 AM   in response to: Bruce McGee in response to: Bruce McGee
It does almost everything I need, which is why I was really happy to
see this feature. I have more stand alone application servers than ones
hosted by IIS.

Never said that Datasnap should not support it. But are you sure of the security of standalone servers compared to IIS? How do you protect certificates private keys on standalone servers? Sure, you can, it's more critical code to write.

Self signed certificates seem to be fine for encryption. Don't worry, I
can't imagine using one for a public facing service.

No, they aren't. Self signed certificates are not secure. Everybody can make one. Even in a LAN, do you trust each and every user? There's also data protection regulations, for example here some personal data are highly protected by laws, and any breach can put a company and its executives in big legal troubles.

Client certificates seem complicated. And expensive. I don't think I
know anyone who uses them.

So you trust any client connecting to your application? Here we have cryptographic tokens storing our personal certificates. People do use client certificates as well, especially when access to some informations needs to be hghly controlled and restricted.

As I think about it, I wonder if you can use self signed certificates
on the client side? It's only that initial connection that's
susceptible to MITM attacks, right?

Client certificates are to authenticate the client and allow only the authorized ones. How could you use a self-signed certificate? How could you revoke a self-signed certificate?

And once someone hijacks the handshaking, he has all it needs to read you whole tranmission.

It's one option. And a good one.

Do you know who maintains Apache for Windows? Actually the Apache Foundation doesn't deliver an official Apache build for Windows. You need to use builds made by Apache Lounge, Apache Haus, etc. Could you trust them fully?

Your point that apache isn't updated automatically is valid, but I
don't know how much of a burden it would be. Aren't most patches

At least, upgrading Apache everytime a new release of OpenSSL is available, because Apache uses that. And of course update it each every time a security fix is delivered.

much different. I stopped letting Windows apply its own patches
automatically years ago. Mostly because of rebooting issues.

Still, you have to manage your patch windows. At least for MS patches and whatever your able to deliver through WSUS you have automatic delivery and installation of them.

I don't know. It wasn't in the QC report.
How important is this, objectively, and does a QC report exist?

If you support a proxy, you have to support it fully :) Proxy authentication is not a small feature you can ignore. It's what tells the proxy who you are and what you're allowed to do. A proxy without authentication is mostly a cache and an anonymizing feature, but far less secure. If you can't use SSO features, it means each and every application needs to ask the user its credentials, and store them. If the proxy does use AD for user authentication, it means applications asks for domain credentials. If those are store unsecurely you may guess what the risk is.

I'll post the QC again and hope some more people vote for it.
http://qc.embarcadero.com/wc/qcmain.aspx?d=104755

Thanks.

I don't understand how this is a problem.

End-to-end protection means it's more difficult to sniff data because they are protected between the two endpoints needing to use them, and not just for part ot the path. It's like mail encryption. You can have a protected path between mail servers, but still your mail can be snooped on the server when they are decrypted. If you use S/MIME, for example, the message are protected as soon as the leave the sending client and only the receiving client can decrypt them.

Communication between two DataSnap servers or between a DataSnap server
and some outside service can be encrypted or not as required.
What am I missing?

If the web server performs encryption, it stops at the web server boundary. Behind it, data are already in clear.

I think the vast majority of them are.

Are you sure? If the target is some kind of "web application" maybe. If Datasnap aims to be a generic remoting solutions to cover different needs I believe it doesn't cover many needs.

I can't back it up with numbers, but I have the feeling that HTTP is
being used more than dedicated TCP/IP connections.

HTTP is more used for two reasons: 1) It bypass proxies/FWs which have usually port 80 and 443 open (but stateful ones may still block) 2) Too much people started to make confusion between HTTP and the "Internet" and used HTTP for everything just because a web server took care of communications - using TCP is a bit more complex.

The worst happened when Google had to come up with WebSocket (TCP over HTTP!) because HTTP design has inherent limitations - it was designed for stateless connections where a client makes request to a server - it's not a fully bidirectional protocol like TCP. Still, a lot of software, especially inside LANs, don't use HTTP connections. Just fireup wireshark on your machine and look at how much software communicates without HTTP....

There are still restrictions.

Nothing a commercial company boasting a 30% sale increase each year should not be able to handle.

First, Indy doesn't ship the OpenSSL libraries. You have to download
them separately because of restrictions. That's the point I was making.
I'd be curious to know if they can cite specific reasons or if they
just decided that this is a much simpler solution.

If you're not a company, it's the simplest solution. Still you'll find on SourceForge and other open source repositories a lot of software deliveted with OpenSSL and other encryption libraries.

If you're saying that OpenSSL is unsuitable for security purposes, then
that's a whole other discussion.

It's not unsuitable, but it has shown troubles lately, and Windows has its own support which I would like to see exploited.

Remember the sniping thing.

C'mon. Any company faces regulations issues, from financial ones to safety ones, etc. etc. It's part of the job working on them too. When we had to ship our appliance abroad, besided encryption we had to handle guess what? Electromagnetic compliance regulations, because although our hardware was COTS, we added some specific hardware to Dell hardware, so the original EM compliance of parts was no longer valid, and we had to make it certified.

We could have sent the part separately to customers and told them "hey, install them yourself, configure and test it!". Would have been it professional?

Not everyone. At least some either wrap a third party (like OpenSSL or
CryptoAPI) or leave it to the user to download libraries separately.

I was meaning the commercial companies selling developing tools. If I get tools paying nothing, I could accept it. When I spend $2500, I would like to buy a professional tool where regulation issues are already resolved.

Python and PHP (I think), for example.

PHP downloads comes with OpenSSL inside. Support for encryption is in mcrypt, and you can compile it into PHP using --with-mcrypt.

Python has less functionalities, but Python comes with far less built-in ones compared to PHP, a lot is left to external modules.

If Embarcadero has extra time on their hands, I have a whole wish list
of things I would like them to tackle before shipping their own
encryption library.

I guess they shouldn't - it's a complex task requiring the right expertise.

I'd much rather see a comprehensive wrapper around OpenSSL.

It would be better than nothing, but it would tie them to a library for which Windows will be no longer a primary platform.

I keep the ones my applications use reasonably up to date.

Have fun, and perform a full disk search of OpenSSL libraries. And check the path so the wrong one is not loaded instead of the right one. VMWare alone disseminates OpenSSL libraries everywhere.

Unless there's an emergency, I just make sure the next update of my
software includes the latest version.

Usually, a security flaw is an emergency :)

For example, 1.0.1j will be included with my next updates.

Hope soon, before 1.0.1k will be released...

CryptoAPI is Windows centric, which excludes Mac, iOS and Android.

Exactly. It's the Windows native API. How much do you deploy on Windows and how much on the other OSes?

Someone else pointed out that there are still a lot of XP users out
there who won't get updates. And I would be embarrassed to tell you
when the last update was performed on a Windows 7 machine that I used
recently.

Sure. But's that's up to the system maintainers. I'm responsible of the security I deliver, not of how other people maitain their systems. If I deliver lame security, and outdated libraries, it's my fault. If I deliver application without any known issue at the time and someone installs it on an unpatched machine it's not my responsibility. As well if someone installs HTTP datasnap applications on an unpatched web server with known vulnerability using 512bit certificates from a compromised CA :)

The more I think about it, I would prefer that Embarcadero not wrap a
Windows specific library. Or at least not only a Windows library.
I see that you opened a QC report for this. Nice.

IMHO that would be a very good solution letting the developer use the encryption backend it prefers for a given application.

You can do better than that.

I talked to them directly already. But I'm very sorry I didn't see any improvement in that area.

And that means fewer torches and pitchforks (I know, hyperbole, but let
me have this one) and more time in QC.

You may be right, but it's a bit funny to see extolling the security virtues of "compiled" applications versus the "managed" ones (guess the target were especially Xamarin and RemObjects) while there are significant security issues in the remoting technologies. I understand marketing is marketing... but developers are not "common" customers - it's easy to spot marketing nonsense.

BTW: Xamarin hired Charles Petzold... Embarcadero should probably look for some people like him to advice on Delphi development, especially for areas where it is still weak.
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 26, 2014 4:40 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Sorry for the delay responding.

These are getting long. We'll have to start breaking them up.

Luigi Sandon wrote:

It does almost everything I need, which is why I was really happy to
see this feature. I have more stand alone application servers than
ones hosted by IIS.

Never said that Datasnap should not support it. But are you sure of
the security of standalone servers compared to IIS?

Pretty sure, yes. Also much less overhead.

How do you
protect certificates private keys on standalone servers? Sure, you
can, it's more critical code to write.

For internal applications, I'm not as concerned

Self signed certificates seem to be fine for encryption. Don't
worry, I can't imagine using one for a public facing service.

No, they aren't.

Yes, they are.

We're talking about encryption, not authenticating the server.

In fact, I might be overdoing it a little by encrypting things within
the network.

Client certificates seem complicated. And expensive. I don't think I
know anyone who uses them.

So you trust any client connecting to your application?

Anyone with the proper login credentials, yes.

This includes public facing services. If it's good enough for my bank,
it's good enough for most of my clients.

It's one option. And a good one.

Do you know who maintains Apache for Windows? Actually the Apache
Foundation doesn't deliver an official Apache build for Windows. You
need to use builds made by Apache Lounge, Apache Haus, etc. Could you
trust them fully?

I kind of do, even though I'm not using Apache right now.

In fact, if push comes to shove, and we're talking about the risk of a
back door being introduced, I trust the open source guys more than I
trust Microsoft.

I don't know. It wasn't in the QC report.
How important is this, objectively, and does a QC report exist?

If you support a proxy, you have to support it fully :)

No.

I'm not interested in this all-or-nothing approach.

I'd rather concentrate on specific things that can be improved.

Communication between two DataSnap servers or between a DataSnap
server and some outside service can be encrypted or not as required.
What am I missing?

If the web server performs encryption, it stops at the web server
boundary. Behind it, data are already in clear.

And further communication to another server would (could) also be
encrypted.

I think the vast majority of them are.

Are you sure? If the target is some kind of "web application" maybe.
If Datasnap aims to be a generic remoting solutions to cover
different needs I believe it doesn't cover many needs.

What specific things would you like to see added?

Remember the sniping thing.

C'mon.

I'd rather stick to the pertinent points. We might be making progress.

I was meaning the commercial companies selling developing tools. If I
get tools paying nothing, I could accept it. When I spend $2500, I
would like to buy a professional tool where regulation issues are
already resolved.

Wrapping a third party library would take care of that.

Python and PHP (I think), for example.

PHP downloads comes with OpenSSL inside.

And so does Delphi.

I didn't notice because I download and distribute my own copies.

Python has less functionalities, but Python comes with far less
built-in ones compared to PHP, a lot is left to external modules.

Which we both seem to think is a good idea.

I'd much rather see a comprehensive wrapper around OpenSSL.

It would be better than nothing, but it would tie them to a library
for which Windows will be no longer a primary platform.

Was Windows ever the primary platform?

The way I read it, they are concentrating on core functionality,
removing old and unused code and adding platform specific support where
necessary. The implication being that Windows won't have any less
support than it does now.

Have you read differently?

I keep the ones my applications use reasonably up to date.

Have fun, and perform a full disk search of OpenSSL libraries. And
check the path so the wrong one is not loaded instead of the right
one. VMWare alone disseminates OpenSSL libraries everywhere.

I deploy my copies in the application's directory so I don't need to
care about any other copies on the machine.

For example, 1.0.1j will be included with my next updates.

Hope soon, before 1.0.1k will be released...

Then I will deploy that version. No fuss, no muss.

CryptoAPI is Windows centric, which excludes Mac, iOS and Android.

Exactly. It's the Windows native API. How much do you deploy on
Windows and how much on the other OSes?

Not Mac so much, but Android is in the near future and iOS after that.

With any luck, Linux will be supported soon, and I intend to take
advantage of that, too.

I don't want to be tied to Windows.

You can do better than that.

I talked to them directly already. But I'm very sorry I didn't see
any improvement in that area.

I've mentioned a lot of improvements. This is where we get into trouble
with sweeping statements.

Are you saying that you have specific requirements that haven't been
added or that you would like to see improvements to?

Let's talk about those.

but it's a bit funny to see extolling the security
virtues of "compiled" applications versus the "managed" ones (guess
the target were especially Xamarin and RemObjects) while there are
significant security issues in the remoting technologies.

I think they were targeting Java, and I agree with their assessment.
Decompiling a Java (or C#) application is much easier than with a
compiled application.

it's a separate issue than what we're discussing here. We could go into
it in another thread, if you like.

--
Regards,
Bruce McGee
Glooscap Software
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 27, 2014 1:57 AM   in response to: Bruce McGee in response to: Bruce McGee
Bruce McGee wrote:

Self signed certificates seem to be fine for encryption. Don't
worry, I can't imagine using one for a public facing service.

No, they aren't.

Yes, they are.

We're talking about encryption, not authenticating the server.

Actually, self signed certificates are only fine for encryption
(secrecy) if they are also fine for authentication, and they are,
provided that the client has authentic prior knowledge of them.
Otherwise you might just as well use the anon cipher suites that don't
require a server certificate at all.

And yes, you can theoretically use anon cipher suites securely, but it
requires that you start with an authentication protocol over the
encrypted connection, such as any ZKP password authentication protocol.
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 27, 2014 2:07 AM   in response to: Henrick Hellström in response to: Henrick Hellström
Henrick Hellström wrote:

And yes, you can theoretically use anon cipher suites securely, but it
requires that you start with an authentication protocol over the
encrypted connection, such as any ZKP password authentication
protocol.

...provided that this protocol proves to both ends that the other end
knows the tested secret.
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 27, 2014 2:47 AM   in response to: Henrick Hellström in response to: Henrick Hellström
Henrick Hellström wrote:

Bruce McGee wrote:

Self signed certificates seem to be fine for encryption. Don't
worry, I can't imagine using one for a public facing service.

No, they aren't.

Yes, they are.

We're talking about encryption, not authenticating the server.

Actually, self signed certificates are only fine for encryption
(secrecy) if they are also fine for authentication, and they are,
provided that the client has authentic prior knowledge of them.
Otherwise you might just as well use the anon cipher suites that don't
require a server certificate at all.

I have only used self signed certificates for encryption within a
network. I've always been a little paranoid because of the security
horror stories.

But after this thread, I might look at alternatives to expensive CA
certificates "in the wild". Where it makes sense, of course.

And yes, you can theoretically use anon cipher suites securely, but it
requires that you start with an authentication protocol over the
encrypted connection, such as any ZKP password authentication
protocol.

This is outside of my experience. Do you have a good reference?

--
Regards,
Bruce McGee
Glooscap Software
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 27, 2014 3:00 AM   in response to: Bruce McGee in response to: Bruce McGee
Bruce McGee wrote:

This is outside of my experience. Do you have a good reference?

If it is outside of your experience, it is probably easier if you use a
PKI solution.

FWIW, using self signed certificates over an internal network is not
that hard, because you could simply verify the thumbprint of the server
certificate. Write it down server side, walk over to your client
computer and verify it there.
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 27, 2014 4:29 AM   in response to: Henrick Hellström in response to: Henrick Hellström
Henrick Hellström wrote:
Bruce McGee wrote:

This is outside of my experience. Do you have a good reference?

If it is outside of your experience, it is probably easier if you use a
PKI solution.

Do you have a reference to a good (and hopefully inexpensive) implementation?

FWIW, using self signed certificates over an internal network is not
that hard, because you could simply verify the thumbprint of the server
certificate. Write it down server side, walk over to your client
computer and verify it there.

I don't even go that far. I'm a lot less concerned about potential man-in-the-middle attacks inside a given network. The one case I've had where that was a concern (possibly over blown), they used a CA.

--
Regards
Bruce McGee
Glooscap Software
Henrick Hellström

Posts: 144
Registered: 12/18/00
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 27, 2014 6:16 AM   in response to: Bruce McGee in response to: Bruce McGee
Bruce McGee wrote:

Henrick Hellström wrote:
Bruce McGee wrote:

This is outside of my experience. Do you have a good reference?

If it is outside of your experience, it is probably easier if you
use a PKI solution.

Do you have a reference to a good (and hopefully inexpensive)
implementation?

Our own, of course: http://www.streamsec.com/index.php?id=strsecii

FWIW, using self signed certificates over an internal network is not
that hard, because you could simply verify the thumbprint of the
server certificate. Write it down server side, walk over to your
client computer and verify it there.

I don't even go that far. I'm a lot less concerned about potential
man-in-the-middle attacks inside a given network. The one case I've
had where that was a concern (possibly over blown), they used a CA.

I am not sure it is such a good idea to place too much trust in the
integrity of the internal network. I suppose all internal traffic
travels through a router that is also connected to an external network
(or directly to the Internet)? What if the router is hacked from
outside? When was the last time you updated the router firmware?
Bruce McGee

Posts: 1,716
Registered: 9/30/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 27, 2014 10:42 AM   in response to: Henrick Hellström in response to: Henrick Hellström
Henrick Hellström wrote:
Bruce McGee wrote:

Henrick Hellström wrote:
Bruce McGee wrote:

This is outside of my experience. Do you have a good reference?

If it is outside of your experience, it is probably easier if you
use a PKI solution.

Do you have a reference to a good (and hopefully inexpensive)
implementation?

Our own, of course: http://www.streamsec.com/index.php?id=strsecii

That might have seemed like a setup question, but I honestly didn't know.

Thanks

I am not sure it is such a good idea to place too much trust in the
integrity of the internal network. I suppose all internal traffic
travels through a router that is also connected to an external network
(or directly to the Internet)? What if the router is hacked from
outside? When was the last time you updated the router firmware?

Point taken.

I can't very well tell Luigi that I make sure my apps use OpenSSL because I don't want to trust sysadmins to perform updates and then turn around and say that the people in charge of the router should make sure it's up to date.

Can you point me to something to help me get started with this, but not have to rely on buying and managing certificates? Preferably something tailored to my lack of experience that goes slowly and uses small words.

--
Regards
Bruce McGee
Glooscap Software
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 20, 2014 1:04 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Hello,

looks like something bad happened now regarding encryption.
According to the following online article of a well respected German IT
magazine (article is in German of course) the US trade ministry now put
a fine on Wind River for delivering encryption software to Hongkong,
Russia and China but as well to Israel, South Korea and South Africa.
For the latter states there were no export restrictions up to now
(according to the article):

http://www.heise.de/newsticker/meldung/USA-bestraft-Export-von-Verschluesselungssoftware-2427683.html

Greetings

Markus
Jouni Aro

Posts: 86
Registered: 9/4/97
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 21, 2014 1:27 AM   in response to: Markus Humm in response to: Markus Humm
On 20/10/14 23:04, Markus Humm wrote:
Hello,

looks like something bad happened now regarding encryption.
According to the following online article of a well respected German IT
magazine (article is in German of course) the US trade ministry now put
a fine on Wind River for delivering encryption software to Hongkong,
Russia and China but as well to Israel, South Korea and South Africa.
For the latter states there were no export restrictions up to now
(according to the article):

http://www.heise.de/newsticker/meldung/USA-bestraft-Export-von-Verschluesselungssoftware-2427683.html

The original article seems to be

http://www.bis.doc.gov/index.php/about-bis/newsroom/press-releases/107-about-bis/newsroom/press-releases/press-release-2014/763-intel-subsidiary-agrees-to-750-000-penalty-for-unauthorized-encryption-exports

http://tinyurl.com/mau85rk

Intel Subsidiary Agrees to $750,000 Penalty for Unauthorized Encryption Exports
WASHINGTON – The U.S. Department of Commerce’s Bureau of Industry and Security (BIS) today announced that Wind River Systems of Alameda, Calif., a wholly-owned subsidiary of Intel Corporation, has agreed to a $750,000 civil penalty to settle charges that it sold encryption software products to foreign government customers and to organizations identified on the BIS Entity List without the required Department of Commerce licenses.

In April 2012, Wind River Systems voluntarily disclosed to BIS that between 2008 and 2011 the company made 55 exports of operating software valued at $2.9 million to governments and various end users in China, Hong Kong, Russia, Israel, South Africa, and South Korea. The operating software is controlled under Export Administration Regulations for national security reasons, and some of the export recipients in China are on the BIS Entity List.

“I approved penalties in this case because the violations were ongoing over a period of several years,” said Assistant Secretary of Commerce for Enforcement, David W. Mills. “Because the violations were voluntarily disclosed, the company received significant mitigation. This penalty should serve as a reminder to companies of their responsibility to know their customers and, when using license exceptions, to ensure their customers are eligible recipients.

BIS controls exports and reexports of commodities, technology, and software to support national security and foreign policy, including nuclear, chemical and biological weapons, and missile non-proliferation, human rights, regional stability, and curbing terrorism. Criminal penalties and administrative sanctions can be imposed for violations of the Export Administration Regulations. For more information, please visit www.bis.doc.gov.

Looks like the customers in the "legal" countries have been on a banned
list. Not the complete countries.
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 21, 2014 3:53 AM   in response to: Jouni Aro in response to: Jouni Aro
The key is:

"some of the export recipients in China are on the BIS Entity List"

"when using license exceptions, to ensure their customers are eligible recipients." (bold mine).

because:

"Section 744.1(c) of the EAR prohibits the use of license exceptions for almost all exports and reexports to listed entities"

And a listed entity is:

"The Bureau of Industry and Security (BIS) publishes the names of certain foreign persons – including businesses, research institutions, government and private organizations, individuals, and other types of legal persons - that are subject to specific license requirements for the export, reexport and/or transfer (in-country) of specified items."

You can find the list here: http://www.ecfr.gov/cgi-bin/retrieveECFR?gp=1&SID=9ae4a21068f2bd41d4a5aee843b63ef1&ty=HTML&h=L&n=15y2.1.3.4.28&r=PART#ap15.2.744_122.4

For license exceptions, see http://www.bis.doc.gov/index.php/policy-guidance/encryption/encryption-faqs#7

It's an interesting reading, you should careful about selling in Canada too - and even Finland :)

Maybe someone at Embarcadero should attend:

http://www.bis.doc.gov/index.php/component/content/article/81-compliance-a-training/export-administration-regulations-training/seminar-details/746-december-3-2014-austin-tx-technology-encryption-controls

"This program is an in-depth session that will focus on the unique provisions related to encryption under the Export Administration Regulations (EAR). Bureau of Industry & Security (BIS) encryption specialists will cover a variety of topics, including how items with encryption functionality are classified under the EAR; how the provision for "mass market" encryption may apply to products; license exceptions for encryption source code (open source and proprietary) and for exports to U.S. subsidiaries and certain eligible countries; encryption registration, classification and reporting requirements; Encryption Licensing Arrangements; conditions placed on encryption licenses, and encryption technology issues."

I expect any company selling worldwide has a grasp of "Recommended prerequisite: Essentials of Export Controls or Complying with U.S. Export Controls or equivalent experience."
Steve Faleiro

Posts: 77
Registered: 3/11/01
Re: Security of Delphi remoting frameworks
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 28, 2014 9:37 PM   in response to: Luigi Sandon in response to: Luigi Sandon
I found the following recent article hosted on The VAR Guy about information/technology security:

http://thevarguy.com/blog/security-audit-and-testing-your-network-secure

I'm fortunate that worked at a great company with a really great learning environment and I also at the same time had a really great manager back in the day who taught me a great deal about implementing (and thus the design of) information and program security ;)

--
Steve Faleiro
A Hardcore Delphi Programmer from India

Happy Halloween 2014!

Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02