• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
Collapse

You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:

  • You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
  • You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
  • If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.

Previously on "Encrypting data in transit"

Collapse

  • AnotherJohnDoe
    replied
    Originally posted by original PM View Post
    Woo hoo.

    So we have done our 'encrypting data at rest' bit of work.

    And now we are being told to 'encrypt data in transit'.

    Unsurprisingly I am getting a lot of different answer non of which make sense.

    So lest assume we want to encrypt a web service - so it needs to be sent as an https message rather than http - I am being told we need to encrypt that somewhere in the application.

    However my understand was that it is just a mode of transport for the message - so i could send the same message via either http or https but the one which goes via https is 'more secure' and 'more difficult for someone to intercept and read' than the one going via http.

    Appreciate this is a large topic but can anyone shed any light on this?

    https is an encrypted form of http
    When your web browser connects to a web server using http then nobody asks for encryption. But if you connect to it using https then both parties agree to encrypt the connection
    But encryption comes down to what the application is, what the client asks for and if the application offers an encryption protocol
    I.E. your web server may support encrypted connections, but if the client asks for an unencrypted one then the connection will be unencrypted
    Having said, some web servers these days will redirect an http request to an https one so that encryption is enabled by default

    Leave a comment:


  • rocketjet
    replied
    Originally posted by original PM View Post
    Cheers for that - when I spoke to our network guys they started banging on about security in the application - but I guess there are two things to consider

    1) The application talking to the database.
    2) The application talking to another application.

    Can you approach both of these in the same way or do they need to be considered differently?
    I think you need the client to clarify the requirements. They need to provide more information in regards to what level of encryption is required as there are many ciphers/algorithms AES-128-CBC, AES-256-CBC, AES-128-GCM, etc. Then we come onto the authentication, which can be as simple as a shared key between servers or use advanced PKI x509 certificates, etc.

    Not sure what database product you are using but MS SQL Server supports TLS.

    https://support.microsoft.com/en-gb/...oft-sql-server

    Leave a comment:


  • amanwhoisquiet
    replied
    Originally posted by original PM View Post
    Thanks much appreciated!

    In terms of what they want - they have no idea - KPMG have come in and said here are your GDPR gaps and so they are saying they need it. (note it is not even a GDPR gap as nowhere does GDPR insist on having encrypted messages within a firewall network)

    But they do not really know what benefit it actually gives as they are just box ticking moron's.
    Lots of places unencrypt traffic as soon as it gets inside their network. It's about where your controls for such things sit. If a customer fires over a CC number to your site, you'll need to unencrypt it eventually or you'd never be able to process it. And you might want to watch what customers are doing on your site, to check they're not up to any funny business, again, which you can only see if it's in the clear at some point before the servers.
    As long as you can demonstrate that the area of the network where those things travel unencrypted is secure, then that's probably enough, but you will get someone trying to score easy audit-points saying that you have to have it encrypted anyway, and because it's possible and the higher-ups will be risk-averse, then you'll end up doing it.

    Leave a comment:


  • minestrone
    replied
    I would be pretty sure these would always be done differently. SQL connections can be encrypted fairly easily by configuration on most databases.

    Between applications I would suggest just writing some encryption code in the application ( which is a small job ) and passing round public keys.

    Leave a comment:


  • original PM
    replied
    Originally posted by rocketjet View Post
    If all you need to do is to encrypt data between two nodes using https then I suggest you research TLS and certificates. Not sure your exact requirements but most web servers such as IIS, Apache, nginx, etc support TLS. If you are using a broker such as RabbitMQ this supports TLS too.

    https://en.m.wikipedia.org/wiki/Tran...Layer_Security

    https://www.rabbitmq.com/ssl.html

    Feel free to PM me if you need more info.
    Cheers for that - when I spoke to our network guys they started banging on about security in the application - but I guess there are two things to consider

    1) The application talking to the database.
    2) The application talking to another application.

    Can you approach both of these in the same way or do they need to be considered differently?

    Leave a comment:


  • minestrone
    replied
    Just reverse the byte stream until is gets to the destination.

    Nobody is going to know any different.

    Leave a comment:


  • TonyF
    replied
    Originally posted by SimonMac View Post
    Random fact I learnt this week, Cerberus the name of the muti headed hound of hell comes from the word k̑érberos, meaning "spotted".

    So Hades, lord of the dead, named his pet dog spot
    Hades was god of the underworld, Thanatos was the god of the dead

    Leave a comment:


  • stek
    replied
    Originally posted by rocketjet View Post
    If all you need to do is to encrypt data between two nodes using https then I suggest you research TLS 1.2 and certificates. Not sure your exact requirements but most web servers such as IIS, Apache, nginx, etc support TLS 1.2.

    https://en.m.wikipedia.org/wiki/Tran...Layer_Security

    Feel free to PM me if you need more info.
    OP mentions messages and message broker and i know WAS does end to end krb5p encryption.

    If its a big environment and using certs probs gonna need a lot of HSM’s.

    Leave a comment:


  • rocketjet
    replied
    If all you need to do is to encrypt data between two nodes using https then I suggest you research TLS and certificates. Not sure your exact requirements but most web servers such as IIS, Apache, nginx, etc support TLS. If you are using a broker such as RabbitMQ this supports TLS too.

    https://en.m.wikipedia.org/wiki/Tran...Layer_Security

    https://www.rabbitmq.com/ssl.html

    Feel free to PM me if you need more info.
    Last edited by rocketjet; 28 March 2018, 15:43.

    Leave a comment:


  • SimonMac
    replied
    Originally posted by stek View Post
    Kerberos? Krb5p....
    Random fact I learnt this week, Cerberus the name of the muti headed hound of hell comes from the word k̑érberos, meaning "spotted".

    So Hades, lord of the dead, named his pet dog spot

    Leave a comment:


  • original PM
    replied
    Originally posted by stek View Post
    Yes kerberos is an common authentication method. Normally just for logging on etc but can be extended to all traffic not just user/pass - there will be a performance hit - ive used it for NFSv4 and to be honest not really noticed any.

    It can all get rather arcane but a product like Centrify makes it much easier.

    WRT internal traffic, if thats what they want....
    Thanks much appreciated!

    In terms of what they want - they have no idea - KPMG have come in and said here are your GDPR gaps and so they are saying they need it. (note it is not even a GDPR gap as nowhere does GDPR insist on having encrypted messages within a firewall network)

    But they do not really know what benefit it actually gives as they are just box ticking moron's.

    Leave a comment:


  • stek
    replied
    Yes kerberos is an common authentication method. Normally just for logging on etc but can be extended to all traffic not just user/pass - there will be a performance hit - ive used it for NFSv4 and to be honest not really noticed any.

    It can all get rather arcane but a product like Centrify makes it much easier.

    WRT internal traffic, if thats what they want....

    Leave a comment:


  • original PM
    replied
    Originally posted by stek View Post
    Kerberos? Krb5p....
    Cheers much appreciated

    So lets assume we are passing these messages around a secure network (e.g. inside companies firewall) - is Kerberos still a thing?

    Also we are very much a Microsoft company and this seems to be the default method for Windows machines?

    In addition to this the messages we send go through a message broker - which needs to read the message to know where to route it - and this would need to decrypt the message, read it the encrypt it again.

    So does that add an overhead?

    Is there really that much benefit in encrypting messages in transit within your own network?

    TIA!

    Leave a comment:


  • stek
    replied
    Kerberos? Krb5p....

    Leave a comment:


  • woohoo
    replied
    You called??

    Leave a comment:

Working...
X