I have implemented a postfix mail receiving server. On this server I am receiving mails coming from Blackberry too.
Since Blackberry implements Sender Rewrite Scheme (SRS), I want to know how can I validate the authenticity of the SRS present in the incoming mails.
Sample email header that contains Blackberry SRS:
Authentication-Results: dev1.cpgtest.ostinet.net; sender-id=neutral header.from=xxxxxxxxxxx#aol.com; spf=pass smtp.mfrom=SRS0=nRLNv7=UW=aol.com=xxxxxxxxxxx#srs.bis7.eu.blackberry.com
thanks in advance
Ashish Sharma
Only the server that has implemented SRS can verify the authenticity of the SRS.
For third parties, above is possible if some external API is available.
Related
I am developing an online-shop based on a Telegram Bot, and I need to host it on a VPS. What are the dangers if I use a self-signed SSL certificate?
I found online that there's a MiTM attack threat, but I couldn't find a detailed explanation on how it can be avoided when using a self-signed SSL.
For example, will it help if all requests are sent to/from a URL of type: www.example.com/?
This is based on my reading of the Telegram Bot API.
There are two ways to control your bot, both of which involve "reasonably" secure protocols that are hard to man-in-the-middle (MITM). First, all communications with the Telegram server using the Bot API uses HTTPS. You must authenticate the Telegram server by doing a proper certificate chain validation. Telegram both authenticates you and identifies you by checking the token you supply in your HTTP request. This token was given to you when you created your bot and must remain a secret.
In addition, you may also elect to receive updates via a webhook. This basically involves you running an HTTPS server using a self-signed certificate. However, you provide your certificate to Telegram over a secure mutually authenticated connection when you setup the webhook, so this eliminates the MITM threat. The Telegram documentation suggests a method you can use to verify that the connection is coming from Telegram.
CAVEATS:
I've never implemented a Telegram Bot, so this is just based on reading the Docs.
Simply because it looks secure to me after 10 minutes of study doesn't make it so. Since this is a unique protocol within HTTPS I would want to see some expert analysis before I'd be confident.
My question is about networking. I'm just looking for a simple answer, yet I couldn't find one after 1 hour research. I know there are techniques such as Wi-Fi Hotspot, man-in-the-middle-attack, local network, echo switch, etc. But I couldn't find an answer to my specific question.
Let's say, client A wants to communicate with server B, and server B says client A must authenticate himself via HTTP basic authentication first. My question is, what happens if client A sends the authentication credentials via HTTP layer (insecure), who can read the HTTP headers that the client A sends to server B over the internet? Would it be easy to do that? Like placing a breakpoint between two arbitrary routers, which help to transfer the packets across the internet, in order to read those headers? How does it work in general?
Thank you!
PS.: I am not trying to learn and do it. I just want to know, how dangerous it would be, if the HTTP basic auth is made via the insecure HTTP layer.
Who can read the HTTP headers that the client A sends to server B over
the internet?
Your Network Provider (e.g Wi-fi hotspot Provider).
Your Domain Name System server (DNS, as 192.168.1.1).
Your Internet Service Provider (ISP).
Your Virtual Private Network if using one (VPN server).
Yourself Or a Virus.
and here comes the HTTPS (HTTP + SSL Encryption)
SSL is about communicating in a language that you and the server only understand.
How dangerous it would be if the HTTP basic auth is made via the insecure HTTP layer?
Well, from above, You can totally get that a simple virus or even a public Wi-fi Hotspot Device can capture and see all of your data if the communication was done in a plain HTTP Socket.
A Simple packet may contain all of your Device information including its basic contents as your passwords, credit cards information, The HTML form for the signup/login that you've just completed with all its data, VoIP Calls and messages being sent to the server + upcoming/received ones.
that's why we need SSL encryption and the server should have a valid SSL certificate too.
By the way, your device may have sent thousands of packets while you read this now!
Capturing the packets that your device sends or even the packets that other devices on your network send can be done through any packet capturing tool or software as Wireshark.
I'm trying to understand how to send encrypted email from an ASP.NET application using an SMTP server set up on IIS. Apologies in advance if I'm not being clear - I'm fundamentally a programmer and my understanding of email is limited.
I know that the SMTP server can be configured to insist on TLS/SSL encryption. What I'm not clear about is how this works with the EnableSsl property of System.Net.Mail.SmtpClient() and the implications when sending to recipients which don't support encryption.
My goal is to ensure that emails sent to certain recipients are always encrypted, but I don't want emails to fail when sent to other recipients whose receiving SMTP servers don't support encrypted messages.
Is it possible therefore to use SSL conditionally in my scenario based on the intended recipient?
Usually mail is delivered to a mail server local to the sender, i.e. your "SMTP server set up on IIS". This mail server then looks up which servers are responsible for the recipients domain and forwards your mail to these servers.
While you can control how the connection is done between your application and your SMTP server (i.e. TLS or not) you have no control how this mail is forwarded from there on. But modern mail servers typically use TLS if the remote mail server offers support for it and fall back if TLS is not supported by the remote server.
I'm able to make HTTP requests on my local host using client certificates.
I have some logic in my code that can make two requests use the same certificate for their requests, or not, depending on certain conditions.
My localhost is currently pointing to the default 'Welcome to IIS' page.
Is there any way to use Wireshark to detect if the client certificates that are being sent from my machine in separate requests are the same or not?
PS: If someone can suggest a better way of achieving what I'm trying to do here, that'd work as well. I don't necessarily need to use Wireshark. My main objective is to figure if two different requests are sending the same cert or not, as I've mentioned here:
How do I monitor client certs that are being sent via the requests?
Thanks!
I found a way to do this. This guide helped, in summary, yes, you can use Wireshark to examine what client certificates are being sent from the client (or received on the server).
You need to start capturing traffic on Wireshark, only for the period of time when the request(s) is made and processed, and then add the appropriate filters to filter based on the protocol. In my case, I filtered it based on the IP address of the sender and receiver because I knew both.
You'll need the server's certificate to decrypt the messages because they'll be transmitted in encrypted format. You can easily do that by going to Edit -> Preferences. Select Protocols from the menu on the left -> SSL -> Click edit. Add the server's cert and IP, and save the settings.
What makes https more secure than http?
The short answer is that https communication between your browser and the server are encrypted. While http traffic is sent in plain text. This means that anyone who can listen to the traffic can read it - this would include usernames and passwords). It also verifies the server to which you are connecting.
That it is encrypted. Read: en.wikipedia.org/wiki/HTTP_Secure
Anything not over HTTPS can be read by anyone snooping on your network.
Im quoting:
Hypertext Transfer Protocol Secure (HTTPS) is a combination of the Hypertext Transfer Protocol with the SSL/TLS protocol to provide encryption and secure identification of the server.
More information on TLS:
The TLS protocol allows client/server applications to communicate across a network in a way designed to prevent eavesdropping and tampering. TLS provides endpoint authentication and communications confidentiality over the Internet using cryptography. TLS provides RSA security with 1024 and 2048 bit strengths.
Also, HTTPS verifies that the site is who it claims to be, if the certificates are correct (signed by a known CA).
All traffic is encrypted. No one on your network can see what is going on (except for knowing where those packets are going to).
The identity of the remote server can be verified using certificates. So you also know that it really is your bank that you are talking to.
Optionally (and not in wide-spread use), the identity of the client can also be verified using certificates. This would allow for secure login to a site using chip cards instead of (or in addition to) passwords.
I want to be really pedantic, as I'm a security nerd :)
HTTPS uses SSL, and it's IETF-ratified cousin, TLS. SSL/TLS can offer four security services:
1) server authentication
2) channel encryption
3) channel tamper detection
4) client authentication
Usually you'll get server auth for free, but only if the host name and the common name in the server's SSL/TLS certificate match. If they don't match your browser will warn you. You usually get the channel defenses for free too, but that's only because the server and client negotiate to require such defenses. In theory, but rarely in practice, a server and client could agree to not use one or more of the channel defenses.
Finally, client authentication is when the server wants you to present a certificate (actually, to prove you have an associated private key) to verify you are you. Client authentication is rarely used.