I have a question about HTTPS and HTTP Authentication credentials.
Suppose I secure a URL with HTTP Authentication:
<Directory /var/www/webcallback>
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /var/www/passwd/passwords
Require user gooduser
</Directory>
I then access that URL from a remote system via HTTPS, passing the credentials in the URL:
https://gooduser:secretpassword#www.example.com/webcallback?foo=bar
Will the username and password be automatically SSL encrypted? Is the same true for GETs and POSTs? I'm having a hard time locating a credible source with this information.
Will the username and password be automatically SSL encrypted? Is the same true for GETs and POSTs
Yes, yes yes.
The entire communication (save for the DNS lookup if the IP for the hostname isn't already cached) is encrypted when SSL is in use.
Yes, it will be encrypted.
You'll understand it if you simply check what happens behind the scenes.
The browser or application will first break down the URL and try to get the IP of the host using a DNS Query. ie: A DNS request will be made to find the IP address of the domain (www.example.com). Please note that no other information will be sent via this request.
The browser or application will initiate a SSL connection with the IP address received from the DNS request. Certificates will be exchanged and this happens at the transport level. No application level information will be transferred at this point. Remember that the Basic authentication is part of HTTP and HTTP is an application level protocol. Not a transport layer task.
After establishing the SSL connection, now the necessary data will be passed to the server. ie: The path or the URL, the parameters and basic authentication username and password.
Not necessarily true. It will be encrypted on the wire however it still lands in the logs plain text
Related
Short story
I'm trying to send a POST request from a PL/SQL script using the utl_http utility in Oracle. I've been able to send the request using http, but not https. I've added what I thought was the necessary certificates to a Oracle Wallet, and I believe they are being imported and used (but in all honesty, this is a little hard to verify). My current assumption is that calls from our DB server are passing through a proxy server, and that that is somehow messing up some part of the https / certificate functionality.
Supporting evidence (possibly?): I tried to make calls (POST requests) to a dummy service at webhook.site. Again, I got this working with http, but not https - the latter results in a cert validation error.
I then tried to replicate the behavior using postman, and that basically produces the same result, unless I fiddle around with the settings:
Initial Postman result:
Could not get any response
There was an error connecting to https://webhook.site/950...
Disabling SSL verification
Under the Post man settings, I turned off SSL Certificate Verification, and tried again. This time, I got a 200 OK response, and confirmed that the webhook received the post request fine.
It seems clear that the error is due to a missing cert, but I can't figure out which, or how to configure it. My assumption is that if I can get this to work for a webhook-url from Postman (without disabling cert verification), then I should also be able to get it to work from PL/SQL later.
When I look at the webhook site in a browser and inspect the certs, the webhook cert is the lowest cert (leaf node?). Above it there is one intermediate cert related to the company I'm working for, and then a root cert also related to the company. The root node is named something like "Company Proxy Server CA" - So I'm assuming the proxy somehow manipulates my requests and inserts it's own cert here.
I've tried downloading all of these certs and importing them into my cert store, as well as importing them under the Postman settings (under Certificates) in various combinations, but nothing seems to make any difference; all attempts at posting with HTTPS produces the following error in my Postman Console:
POST https://webhook.site/9505...
Error: unable to verify the first certificate
Any ideas about how to resolve this, or at least obtain more information about what to do would be greatly appreciated.
Switching OFF "SSL Certificate Verification" in Postman only means that it (i.e. Postman) will not check the validity of SSL certificates while making a request. Meaning that it will just send the certificates as they are. Because your connection fails if the setting in ON, this means Postman cannot verify the validity of your certificates.
This is most likely the case with the actual service you're trying to POST to, they cannot verify the certificates. Is that service outside your company network? And is it a public one or one owned by your company? Where is that service hosted? What certificate do they need?
BTW, TLS client certificates are sent as part of establishing the SSL connection, not as part of the HTTP request. The TLS handshake (and exchange/validation of client and server certificates) happens before any HTTP message is sent.
I'm thinking this might be a blocked port issue.
You said... ""Company Proxy Server CA" - So I'm assuming the proxy somehow manipulates my requests and inserts it's own cert here."
That means your client software needs your Company Proxy Server CA in its trusted certificates list. If that client's list is that of the oracle wallet...
https://knowledge.digicert.com/solution/SO979.html
This talks about how to do that.
Also, if your system running postman has a non-oracle based wallet trusted certificate (probably the operating system?) you'll have to execute something like adding the trust to your account on the workstation
https://www.thewindowsclub.com/manage-trusted-root-certificates-windows
in order to have the proxy server certificate trusted.
Once the certificate you're making the connection with has a root of trust per the effective configuration of the client being used, then you'll be able to verify the certificate.
A couple of possible issues:
The server doesn't actually support HTTPS. Connect a browser to the URL that you POST to, and see if you receive a response. (It looks like you already did this, but I'm documenting it for completeness.)
The server uses the Server Name Indication (SNI) extension to determine what certificate chain to send back, but your POSTing client doesn't send that extension. You can identify this case by looking up the IP for the host you're POSTing to, then going to https://nnn.nnn.nnn.nnn/ (obviously use the IP here, instead of the literal string 'nnn.nnn.nnn.nnn') in your browser, and checking the certificate chain it returns. If it is not the same as you get from step 1, this is your problem, and you need to figure out how to either get SNI support in your Oracle PL/SQL client or get the POST endpoint exposed on that hostname. (alternatively, you might be able to use these certificates to prime your Oracle Wallet, but they might have an issue with the hostname in the certificate not matching the hostname you connect to.)
You have a proxy in the way. I don't think this is what's going on, since that would basically only cause problems if you were doing client-side certificate authentication. (If this is the problem or is a condition, you need to import those certificates into your trusted wallet; you also need to ensure that the server you're posting from is going through the same proxy. Otherwise, you need to ensure that the certificate authority for the proxy that the machine actually running the code sees is in the wallet. This may require the assistance of the system/network administrators who run that machine and its connection to the network.)
HTTPS is a finicky beast. Many, many things must work exactly correctly for TLS connections to work and the certificates to correctly verify (the TLS port must respond, the client and server must agree to speak the same version of TLS, the client and server must agree to use the same cipher combination, the certificate chain presented by the server must be issued by a CA the client recognizes, and the leaf certificate in that chain must certify the name client requested).
SNI is needed to support multiple names on a single host without messing with the certifications of other names on the same host. Unfortunately, SNI is one of those things that has been standardized for over a decade (RFC 3546), but many enterprise-grade softwares haven't implemented.
I am trying to record my application under test which is on the intranet using the Jmeter recording controller. It manages to capture the URL but then starts showing DNS failure and response code 503.There seems to be some authorization issue. Any ideas on how I can provide authorization details (username/password) at the time of recording ?
For application authorization you can try adding HTTP Authorization Manager, it should be able to deal with at least Basic HTTP Authentication
For proxy authorization (if your machine is using proxy for intranet/internet access) you can specify username and password via -u and -a command-line arguments correspondingly like
jmeter -H my.proxy.server -P 8000 -u username -a password -N localhost
HTTP 503 status code indicates that a server is temporarily unable to handle the request.
So it would be a temporary failure of one of the intermediate components between JMeter and the server:
DNS Server
Proxy
Firewall
Load Balancer
Web server (Apache HTTP, Nginx, NodeJS...)
Application Server (J2EE, PHP, ASP servers)
An authentication error related to proxy would trigger a 4XX response code.
Checks the logs of each of the intermediate components , if you don't reproduce issue when using browser then have a look at:
http://jmeter.apache.org/usermanual/get-started.html#proxy_server
I am quite new in learning Networking and stuff related to Servers.
I have a question about FTP server security. Please forgive me if it is too simple.
I have signed up for FTP server and I uploaded a file. The URL of the file is
zanubvideos.ezyro.com/Shortest.mp4. And anyone, who have this URL can access my file anytime anywhere. And I think this has made my file insecure, Isn't it? Then how can we say that FTP is secure?
Please correct me if I am wrong.
install a Secure FTP Server on Windows using IIS. or
you can make FTP secure by using following methods :
1.Disable Anonymous Access
2.Enable Logging
3. Harden your ACLS.
4. Setup your FTP site as Blind Put
5.Enable Disk Quotas.
6.Use Logon Time Restrictions
7.Restrict Access by IP
8.Audit Logon Events
9.Enable Strong Password Requirement
10.Enable Account Lockout and Account Lockout Threshold
for more details visit Steps to a Secure FTP Server
By a sniffer (Fiddler), I can check out the stream sent through my PC to network. Surprisingly, I found when I log in google's account (https), the password is sent in a clear text, e.g.
POST https://accounts.google.com/ServiceLoginAuth HTTP/1.1
...
Email=abc#gmail.com&**Passwd=12345678**
My question is: why the password is passed without encryption even with a https protocol?
HTTPS encrypts the entire request and response.
However, you're telling Fiddler to decrypt using an untrusted root certificate.
In other words, you're MITMing yourself, and telling the browser to ignore the untrusted certificate.
No, the password is not sent without encryption to Google as clear text. Google is using SSL, don't worry. But you installed Fiddler on your PC. When you did so, Fiddler registered a specific root level certificate on your computer and is able to decrypt the traffic between your web browser and the internet. By installing Fiddler, you explicitly granted this application the possibility to decrypt the traffic. So, yeah, anyone able to get administrator access to a PC is able to install a root level certificate to this PC and consequently is able to decrypt all traffic between this PC and the internet. What did you expect? How do you think trojans work?
But any man-in-the-middle attacks won't work because they won't be able to decrypt the SSL traffic between your web browser and the internet.
I work as a student web developer for my computer science department and I've been asked to look into a modification of our password reset procedure for linux accounts. Currently users will log in with their university credentials (via Active Directory) and after being authenticated they get a temporary password through email which they are forced to change as soon as they log in. This way eben if the temporary password it intercepted there is a very short time span in which it could even be used.
Now the idea has been posed that instead of using a temporary password that we might allow the user to pick a new permanent password and set it directly through the web utility. It is my understanding that https is more of "the best we have" than "a great way to secure information". Are there any other avenues I can explore for securing the new password so that we can feel comfortable implementing such a system?
Basically, if you communicate with a server over HTTPS and the private key of the server isn't exposed to someone else, you can be sure that anything you transfer (e.g. the new password) can only be decrypted by the server. Additionally the server certificate assures, that the server you are communicating with, really is the server you want to communicate with.
So, using HTTPS provides authentication and prevents eavesdropping.
If you are working with Active Directory, it is my understanding that the Password Modify Extended Operation (which requires the existing password) is not supported. Therefore, the password must be changed with the LDAP modify request. One solution would be to use the UnboundID LDAP SDK with a web application to execute the LDAP modify with the new password. The modify request should be transmitted over a secure connection, or a non-secure connection promoted to a secure connection using the StartTLS extended operation.
see also
AD password change
Using ldapmodify - this article is about the command line utility ldapmodify but the concepts are useful.