Re: [twsocket] ICS and OpenSSL security

2016-11-04 Thread Richard Christman
Hi Angus,

I can see I must have offended you. I'm sorry for that. Honestly, it
wasn't my intention, but sometimes I can be pretty stupid in my human
relations. So often I say the wrong thing; use the wrong words. I'm
better with computers than with people. In real life, my wife helps out.
She's very extroverted and friendly. She does most of the talking. I
just smile, but damn, I sometimes forget that too!

My statement regarding PGP being a better choice than AuthentiCode, was
uninformed. However, I continue to believe strongly in the PGP signature
for authenticating open-source applications. I see nothing changing in
that regard.

I hope this post will not offend you further, but I'm feeling a little
ticked, myself, by your disdain for open-source developers.

On 11/01/16 12:27 PM, Angus Robertson - Magenta Systems Ltd wrote:
>>> One thing that could be done with a new command batch file is to
>>> digitally sign the OpenSSL DLLs, which you can already do for 
>>> your own customers.
>>
>> You're right. All that's required is a batch file. I PGP sign all 
>> my source and binaries. It's required. 
> 
> Required by whom?  Your end users?  Other developers? 

I'm involved in a specialized high-security linux project that requires
my work be open-source and PGP signed. I've been with the project since
2000.

> No-one else has asked about PGP or signing source or libraries in the
> last six years of mailing archives.  

I can see that this has just never occurred to you before. That's not a
crime.

> And none of us here takes any
> notice of hashes or PGP for source code, we download from trusted
> servers.  

Interesting view of security...ignore it :) Very cavalier though. Even
trusted servers can be hacked and/or otherwise compromised. You know that.

> Sorry if that breaks your chain of trust, but as Rui says, you really
> need to build your own OpenSSL DLLs if you want full traceability,
> otherwise we all need to trust him since he kindly builds the DLLs.  

I can do that.

> When I refer to signing, I'm talking about embedding a signature into
> that application, to stop the application being modified or corrupted
> and prove it's origin, and the application itself should be able to do
> that, as should the OS.  
> 
> Hashes and PGP are separate to the file, so need to be distributed
> separately, not sure how any of that checking can be automated, don't
> recall it ever being discussed in any Delphi component forums.  
> 
>> I'm not sure about your authenticode cert and how the user tests 
>> it. I've seen them available and I know they're expensive. I'm 
>> guessing this is for your commercial software. It's probably not 
>> the best choice for this application.
> 
> Authenticode is the bedrock of Windows application security, almost
> every executable file in the OS is authenticode digitally signed, as
> are most of the main executables in Delphi itself.  Every serious
> application developer has their own authenticode code signing
> certificate, and digitally signs their applications, so their customers
> can be assured of their origin and integrity. 

Your statement, that every 'serious' application developer has an
AuthentiCode cert, is kinda prejudiced. My work is very serious. I've
never ever had a single complaint regarding the authenticity of my work
and not a single complaint regarding it generating warnings.

Your programs must provide significant income. Congratulations on that.

> Modern versions of Windows expect executables to be signed, and display
> warnings if not.  
> 
> Many application developers also include self checks to ensure their
> applications are correctly signed and not corrupted by third parties, I
> have a free Delphi component that does this:
> 
> https://www.magsys.co.uk/delphi/magtrustchk.asp
> 
> Ideally, all DLLs the application loads should also be checked, this
> checking is one of the reasons for the slow start up of recent releases
> of RAD Studio.  But my own applications don't currently check the
> OpenSSL DLLs I use, so I'm breaking my own integrity rules (I also sign
> the setup application, but files can be changed after install). 
> 
> So we do need the OpenSSL DLLs to be digitally authenticode signed,
> which will either be with my certificate and/or an open source Overbyte
> certificate Francois is looking to acquire.  I'll then add a demo or
> something showing how to check the DLLs before loading with my
> component, could even be built into ICS if others believe it's a step
> towards better security.  
>
> OpenSSL functions can also be used to check and create authenticode
> digital signatures, but it's not really safe to check itself.   

You lecture me regarding security that you have never even implemented.
I've signed my work for 16 years!

But really, on the other hand, I'm very happy you've decided you need to
take action. I know you guys want to provide the best possible software
and service possible. You always have. This is good. I'll 

Re: [twsocket] ICS and OpenSSL security

2016-11-01 Thread Angus Robertson - Magenta Systems Ltd
> > One thing that could be done with a new command batch file is to
> > digitally sign the OpenSSL DLLs, which you can already do for 
> > your own customers.
> 
> You're right. All that's required is a batch file. I PGP sign all 
> my source and binaries. It's required. 

Required by whom?  Your end users?  Other developers? 

No-one else has asked about PGP or signing source or libraries in the
last six years of mailing archives.  And none of us here takes any
notice of hashes or PGP for source code, we download from trusted
servers.  

Sorry if that breaks your chain of trust, but as Rui says, you really
need to build your own OpenSSL DLLs if you want full traceability,
otherwise we all need to trust him since he kindly builds the DLLs.  

When I refer to signing, I'm talking about embedding a signature into
that application, to stop the application being modified or corrupted
and prove it's origin, and the application itself should be able to do
that, as should the OS.  

Hashes and PGP are separate to the file, so need to be distributed
separately, not sure how any of that checking can be automated, don't
recall it ever being discussed in any Delphi component forums.  

> I'm not sure about your authenticode cert and how the user tests 
> it. I've seen them available and I know they're expensive. I'm 
> guessing this is for your commercial software. It's probably not 
> the best choice for this application.

Authenticode is the bedrock of Windows application security, almost
every executable file in the OS is authenticode digitally signed, as
are most of the main executables in Delphi itself.  Every serious
application developer has their own authenticode code signing
certificate, and digitally signs their applications, so their customers
can be assured of their origin and integrity. 

Modern versions of Windows expect executables to be signed, and display
warnings if not.  

Many application developers also include self checks to ensure their
applications are correctly signed and not corrupted by third parties, I
have a free Delphi component that does this:

https://www.magsys.co.uk/delphi/magtrustchk.asp

Ideally, all DLLs the application loads should also be checked, this
checking is one of the reasons for the slow start up of recent releases
of RAD Studio.  But my own applications don't currently check the
OpenSSL DLLs I use, so I'm breaking my own integrity rules (I also sign
the setup application, but files can be changed after install). 

So we do need the OpenSSL DLLs to be digitally authenticode signed,
which will either be with my certificate and/or an open source Overbyte
certificate Francois is looking to acquire.  I'll then add a demo or
something showing how to check the DLLs before loading with my
component, could even be built into ICS if others believe it's a step
towards better security.  

OpenSSL functions can also be used to check and create authenticode
digital signatures, but it's not really safe to check itself.   

Angus

  

-- 
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be


Re: [twsocket] ICS and OpenSSL security

2016-10-31 Thread RTT

On 31/10/2016 19:00, rich...@quicksilvercollectibles.com wrote:

I cannot say I know for a fact these binaries came from the
original source code or aren't otherwise tampered with. The original
OpenSSL files you downloaded were signed. Then you don't sign. Then I do
sign. You're sort of a broken link in the security chain.


You can only be sure the binaries are fine, and the result of the 
original source code, if you build them yourself and the system where 
you build them is clean. Providing the hash files for the ICS downloads 
is not a complicated thing, but will only grant you the download wasn't 
tampered, by a  MiM attack (having HTTPS access on overbyte.be would 
reduce this possibility), while downloading.


--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be


Re: [twsocket] ICS and OpenSSL security

2016-10-31 Thread richard
I first sent this from the wrong email address. My apology.

On Fri, 28 Oct 2016 08:24 +0100 (BST), you wrote:
>
> > When downloading ICS and the OpenSSL binaries you provide, I've
> > never been able to find any sig, sha, or md5 files for checking
> > authenticity.
>
> ICS itself is source code, so in theory is not a security risk.

Source code is subject to the same concerns as binaries. When the SSL 
code was added to ICS years back, security became a concern.

> We don't provide any authentication for our builds of the OpenSSL tools
> because no-one has ever asked, and we don't have the means to easily
> automate it.  Doing so would involve time better spent supporting ICS.
>
> You don't have to use the ICS build OpenSSL tools, there are other
> Windows versions out there you can use instead.
>
> One thing that could be done with a new command batch file is to
> digitally sign the OpenSSL DLLs, which you can already do for your own
> customers.

You're right. All that's required is a batch file. I PGP sign all my 
source and binaries. It's required. Your ICS and OpenSSL DLLs are 
included in my releases, and it makes me a little uneasy signing for 
your work as I cannot say I know for a fact these binaries came from the 
original source code or aren't otherwise tampered with. The original 
OpenSSL files you downloaded were signed. Then you don't sign. Then I do 
sign. You're sort of a broken link in the security chain.

I have always trusted you guys implicitly, I feel quite certain 
everything is fine. I will continue to trust you. I appreciate your very 
long and most excellent work. I've been with you since, I think, 1999.

> But ICS does have an authenticode certificate and is not a
> company so might have trouble actually buying one (they are expensive)
> so they'd probably need to be signed by my company as Magenta Systems
> Ltd.  But at least that would protect against tampering.

I'm not sure about your authenticode cert and how the user tests it. 
I've seen them available and I know they're expensive. I'm guessing this 
is for your commercial software. It's probably not the best choice for 
this application.

In the open source world, PGP sigs are universally accepted for this 
purpose. All that's required is the GPG program and creation of a key 
owned by the person signing the release.

I know this is something you haven't considered previously. Early on, 
your work had no security implications at all. I can understand and have 
basically overlooked this all along.

Taking this step would be an important and needed service to all who use 
your ICS/OpenSSL, but if this is too much for you right now, I hope you 
can work it in at some time in the future.

Regards,

Richard
-- 
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be